[OT] Anyone w/ svn->git experience and advice?

[Nick Sabalausky]

"Russel Winder" <russel at russel.org.uk> wrote in message 
news:mailman.305.1326443113.16222.digitalmars-d at puremagic.com...
>I am surprised you had problems with Mercurial and Bazaar, their support
>for working with Subversion is very good.
>

When I asked around the Mercurial scene about doing what I wanted, they 
basically told me that I was wrong for wanting to preserve the empty 
directories that the buildsystem for those old revisions was relying on. And 
they also said that none of the hg/svn tools had any option for inserting 
directory-preserving dummy files.

But my experience attempting Bazaar was much, *MUCH* worse:

I was actually completely sold on going with Bazaar at first. But  first of 
all, *none* of the conversion scripts even *ran*. *At all*. Every single one 
I tried would just crash right out the gate no matter what arguments I gave 
them (or even no args, or --help, etc...). And so I tried Bazaar's Python 
installer, and *that* just kept crashing! Yes, the installer. Someone 
directed me to try a different version, but the links to it were broken! It 
was seriously just one thing after another. Practically nothing worked.

And on top of that, I spent hours trying to find the correct place to ask 
about it all (so if I did manage to ask in the wrong place, it sure as hell 
wasn't for lack of trying). I got two meaningful repies (and one completely 
useless one) to *one* of the posts I made, and they ended up not helping at 
all. My other posts just *sat* there for literally *months* with *zero* 
responses. Here's the posts:

https://bugs.launchpad.net/bzr-windows-installers/+bug/819567
https://answers.launchpad.net/svn2bzr/+question/165994
https://answers.launchpad.net/bzr-fastimport/+question/166680

(The reason I was looking into hg-fast-export was so I could convert one of 
my less important Hg repos to Bzr so I could try out Bzr on one of my 
existing projects.)

So, yea even with the problems I have with Git, it's *still* working out the 
best :/

>Having said this it probably makes sense for D-related repositories to
>be Git ones since D itself is in a Git repository?

Maybe, but the main reasons I'm going with git are the difficulties above, 
and the fact that I like TortoiseGit much better than TortoiseHg (And 
because bitbucket now supports Git. If GitHub were my only Git option, I'd 
use Hg instead.)

>Git doesn't actually understand directories at all, it only deals with
>files and paths.  As I understand it, they hack the above by putting
>hidden files in place.  This really sucks.

Yup :(

>> On one SVN repo:
>> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
>
>This does indeed looks bizarrely odd.
>
>> On the other SVN repo:
>> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
>> ((?-xism:^trunk(/|$)))
>
>Ditto.
>
>Are these to do with the empty directories?

Apperently. It seems to work fine if I omit the --preserve-empty-dirs 
switch. (Or at least it did the one time I tried it by mistake.)

>If so I would just give up
>and live with the fact that Git doesn't understand directories only
>files.

I'm too damn stubborn ;)

>Subversion is not a version control system, it is a versioned filestore
>that can be used for version control.

So it's better? ;) j/k

>Clearly it must understand
>directories as well as files.  Mercurial and Bazaar also understand
>directories as well as files -- Bazaar better than Mercurial overall --
>Git doesn't.

Yea, like I said, I was almost totally sold on Bazaar at one point, but the 
complete lack of support, and the lack of half of it even working at all, 
ended up being dealbreakers.

>When doing conversions from Subversion, I always found it best to mirror
>the Subversion repository locally and then do the conversions as
>operations on local filestore.
>

Yea, in fact I've already gone ahead and done that (together with 
svndumpsanitizer: http://miria.linuxmaniac.net/svndumpsanitizer/ ) to remove 
the executable files.

Maybe I should try removing the downloads dir too...But now I'm just taking 
random shots in the dark :/

>This also of course allows you to manually edit the Subversion
>repository to remove all the crap and then  do the conversion.  No need
>for --ignore-paths and all that technology.  Also you are in control of
>removing the Subversion inconsistencies if there are any.

Hmm...Maybe I could somehow add the .gitignore files to the SVN history 
before git even touches it?

>I wonder if part of the problem is that you are not telling it the
>details of the Subversion repository filestore structure.  I have never
>found that the git-svn defaults work satisfactorily.  If the repository
>has the usual trunk/branches/tags structure then give the -s option,
>otherwise give the --trunk, --branches, and --tags options explicitly.

Yea, it is the usual structure (aside from the additional top-level 
downloads directory). And I included "--trunk=trunk --tags=tags" (there are 
no branches, other than the SVN "tags"). I also tried "-s". No dice. :/

As a side note, Git keeps feeling more and more appropriately-named... ;)