Re: [lmi] Converting a proprietary svn repository to git

[Greg Chicares]

On 2016-02-26 02:01, Vadim Zeitlin wrote:
> On Fri, 26 Feb 2016 00:17:43 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--do you see any real reason not to use 'git svn' in this case,
> GC> particularly with '--no-metadata'?
> 
>  In the simple case "git svn clone" works just fine. Things get more
> complicated if you want to convert the existing branches and tags or want
> to make some changes to the repository structure. I wrote a guide about
> this some time ago if you're curious:
> 
>       http://www.tt-solutions.com/en/articles/advanced_svn_to_git

In that article:
  s/abovet/above/

> but from your description it doesn't seem like you need any of this here.

It is nevertheless extremely interesting. I think I will try this:
  http://www.tt-solutions.com/downloads/msgfilter-rev2sha
instead of '--no-metadata' (and compare the result to a '--no-metadata'
migration).

> GC> # convert svn to git
> GC> /home/greg/tainted/migration/svn_working_copy/repository[0]$cd ../..
> GC> /home/greg/tainted/migration[0]$git svn clone \
> GC>   file:///home/greg/tainted/migration/repository \
> GC>   --authors-file=authors.txt --no-metadata --trunk=/ ./proprietary
> 
>  I guess your svn repository uses non-standard layout, which is why --trunk
> option is needed. But other than this, this is perfectly fine.

It did indeed use a non-standard svn layout:
  svn_working_copy/
    repository/
      data/
        .svn/
      src/
        .svn/
      test/
        .svn/
      .svn/
and after conversion I have:
  proprietary/
    data/  263 files, 12.2MB total
    src/    37 files,  1.4MB total
    test/  156 files, 11.2MB total
    .git/
Should I restructure that? If a different layout would be better, it
makes sense to set it up now. The 'git svn clone' operation, BTW, takes
only two minutes, so it's not hard for me to make big changes here now so
I can present something solid to Kim (whose machine may run much slower
because it uses msw). I have two concrete questions here:

(1) Is there some "standard" layout with an expected main directory
like svn's "trunk"?

(2) Should I use git submodules? (At a quick glance, this seems to bring
little benefit in return for much complexity in our case.)

I guess the answer to both is "no", since my newly-converted repository's
structure look much like this one:
  wxWidgets/
    .git/
    art/
    ...

The subdirectories are interdependent as follows:

- src/ is independent. It contains the source files described here:
    # Files whose names match 'my_%.cpp' are taken as product data files,
    # which are overridden by any customized files found in a special
    # directory.
    vpath my_%.cpp        $(src_dir)/../products/src
  which lmi's makefiles use to build product_files$(EXEEXT).

- data/ depends only on src/ . It contains the xml files created by
  running product_files$(EXEEXT). These files are distributed to users.

- test/ contains the lmi input files (.ill, .cns, etc.) used for
  'make system_test' (which are independent and change infrequently), as
  well as md5sums of the test results (which depend on data/ and also on
  the code in the public lmi repository, and change frequently). The
  regression-test results (about 110MB in 1400 xml files) are not stored
  here; if all the dependencies are right, then Kim's system-test md5sums
  and mine will match perfectly, and we virtually never have cause to
  share any of the 110MB of output files.

We have an absolutely rigid monthly release schedule (for governance
reasons, each end-user distribution is allowed to run only for a single
calendar month). In a typical month, a couple of states might approve a
new product; we record that in src/, which changes a file or two in data/,
and test/ is unchanged. Other, similar changes generally follow a quarterly
or annual schedule. At irregular intervals, we add new testdecks in test/
or modify footnotes in src/; or we implement new products, which lead to
many new files. There have been 237 svn revisions in a four-year history,
which is about one a week.

We need a DVCS because our old habit of sharing a 5MB tarball of the whole
svn repository through email, even if only one line of code changes, has
become wearisome. A central repository is not an option: hosting it on a
third-party site risks data leakage, and the corporation is not capable
of providing reliable hosting itself. Instead, we want to exchange updates
in email.

>  The next step would be to "git push --all" to some bare repository and
> then clone it from somewhere else and verify that everything looks good.

Okay, I'll do that.

Then I have a pending changeset that, in concept, is a simple rename of a
few files in test/ . But first I'll have to get rid of '$Id', which makes
most files mismatch the svn originals, and in particular affects every line
of test/md5sums .