Jump to page: 1 2
Thread overview
[OT] Anyone w/ svn->git experience and advice?
Jan 13, 2012
Nick Sabalausky
Jan 13, 2012
Vladimir Panteleev
Jan 13, 2012
Jacob Carlborg
Jan 13, 2012
Jacob Carlborg
Jan 13, 2012
Nick Sabalausky
Jan 13, 2012
Jacob Carlborg
Jan 13, 2012
Michel Fortin
Jan 13, 2012
Jacob Carlborg
Jan 13, 2012
Nick Sabalausky
Jan 13, 2012
Nick Sabalausky
Jan 14, 2012
Nick Sabalausky
Jan 13, 2012
Russel Winder
Jan 13, 2012
Nick Sabalausky
Jan 13, 2012
Russel Winder
Jan 13, 2012
Russel Winder
Jan 13, 2012
Michel Fortin
Jan 14, 2012
Nick Sabalausky
Jan 13, 2012
Dejan Lekic
Jan 13, 2012
Nick Sabalausky
Feb 05, 2012
Nick Sabalausky
January 13, 2012
I apologize for going so far offtopic with this. But I've taken this to the git mailing list, and after working on it for days it's still not working and I'm just about pulling my hair out. What makes it even more frustrating is that when I attempted SVN->Hg and SVN->Bzr, those were even *more* problematic (especially Bzr).

I know DMD made the switch from SVN to Git at one point, so I'm hoping someone here might be able to help out before I finally go nuts:

Summary:
--------------

I'm trying to use "git svn clone --preserve-empty-dirs ..." (Git v1.7.8.3, Linux) but after it gets through only a fraction of the revisions, it just bails with some cryptic:

On one SVN repo:
Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))

On the other SVN repo:
Failed to strip path 'src/nonFatalAssertTest/.gitignore'
((?-xism:^trunk(/|$)))


The Full Picture:
-------------------------

I want to convert these to Git:

http://svn.dsource.org/projects/semitwist http://svn.dsource.org/projects/goldie

Notes:

- Goldie has some tags.
- Neither repo has branches.
- Being SVN, I wasn't shy about including required empty dirs in the repo
(since every F&*#&$@ filesystem on the G*#$*%^$ planet handles them fine.) I
need to keep these.
- For awhile I had been including compiled binaries in the repo. Don't ask
me why, I just did :) I need to remove these.
- Obviously not interested in preserving the "downloads" directory (just a
DSource-ism anyway).
- Both repos are small enough that known-to-be-slow git-svn should still be
plenty fast enough for this task.

I did get some help at the git mailing list: http://git.661346.n2.nabble.com/SVN-gt-Git-but-with-special-changes-td6840904.html

They showed me how to strip the binaries from the Git repo after it's converted (although I haven't gotten that far yet). And I've found some tutorials that help out with the author conversions, etc. The problem is actually converting the dang repos, and doing it while preserving tags and *all* directories (not just the ones that Git's decided are worthy of existing). But like I said above, git-svn is just crapping out:

$ git svn clone
http://svn.dsource.org/projects/semitwist --prefix=svn/ --preserve-empty-dirs -
-authors-file=semitwistdtools-authors.txt  --trunk=trunk --tags=tags
SemiTwistDTools
...the first few revisions (out of 242 total) here...
r46 = 61d45b1e70c129a5096bb35686f0d024786c1204 (refs/remotes/svn/trunk)
        A       cmdTest.pnproj
Failed to strip path 'src/nonFatalAssertTest/.gitignore'
((?-xism:^trunk(/|$)))

$ git svn clone
http://svn.dsource.org/projects/goldie --prefix=svn/ --preserve-empty-dirs --authors-file=goldie-authors.txt
--trunk=trunk --tags=tags Goldie
...the first few revisions (out of 557 total) here...
r85 = 60d792abf9957f41f70d7ae399fee7ecda0b66f1 (refs/remotes/svn/trunk)
        M       README.txt
Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))


January 13, 2012
On Friday, 13 January 2012 at 03:32:03 UTC, Nick Sabalausky wrote:
> On one SVN repo:
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))

--preserve-empty-dirs works by putting a dummy file inside empty directories. The file name is ".gitignore". It looks like --preserve-empty-dirs is broken for your case.
January 13, 2012
On 2012-01-13 04:32, Nick Sabalausky wrote:
> I apologize for going so far offtopic with this. But I've taken this to the
> git mailing list, and after working on it for days it's still not working
> and I'm just about pulling my hair out. What makes it even more frustrating
> is that when I attempted SVN->Hg and SVN->Bzr, those were even *more*
> problematic (especially Bzr).
>
> I know DMD made the switch from SVN to Git at one point, so I'm hoping
> someone here might be able to help out before I finally go nuts:
>
> Summary:
> --------------
>
> I'm trying to use "git svn clone --preserve-empty-dirs ..." (Git v1.7.8.3,
> Linux) but after it gets through only a fraction of the revisions, it just
> bails with some cryptic:
>
> On one SVN repo:
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
>
> On the other SVN repo:
> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
> ((?-xism:^trunk(/|$)))
>
>
> The Full Picture:
> -------------------------
>
> I want to convert these to Git:
>
> http://svn.dsource.org/projects/semitwist
> http://svn.dsource.org/projects/goldie
>
> Notes:
>
> - Goldie has some tags.
> - Neither repo has branches.
> - Being SVN, I wasn't shy about including required empty dirs in the repo
> (since every F&*#&$@ filesystem on the G*#$*%^$ planet handles them fine.) I
> need to keep these.
> - For awhile I had been including compiled binaries in the repo. Don't ask
> me why, I just did :) I need to remove these.
> - Obviously not interested in preserving the "downloads" directory (just a
> DSource-ism anyway).
> - Both repos are small enough that known-to-be-slow git-svn should still be
> plenty fast enough for this task.
>
> I did get some help at the git mailing list:
> http://git.661346.n2.nabble.com/SVN-gt-Git-but-with-special-changes-td6840904.html
>
> They showed me how to strip the binaries from the Git repo after it's
> converted (although I haven't gotten that far yet). And I've found some
> tutorials that help out with the author conversions, etc. The problem is
> actually converting the dang repos, and doing it while preserving tags and
> *all* directories (not just the ones that Git's decided are worthy of
> existing). But like I said above, git-svn is just crapping out:
>
> $ git svn clone
> http://svn.dsource.org/projects/semitwist --prefix=svn/ --preserve-empty-dirs -
> -authors-file=semitwistdtools-authors.txt  --trunk=trunk --tags=tags
> SemiTwistDTools
> ...the first few revisions (out of 242 total) here...
> r46 = 61d45b1e70c129a5096bb35686f0d024786c1204 (refs/remotes/svn/trunk)
>          A       cmdTest.pnproj
> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
> ((?-xism:^trunk(/|$)))
>
> $ git svn clone
> http://svn.dsource.org/projects/goldie --prefix=svn/ --preserve-empty-dirs --authors-file=goldie-authors.txt
> --trunk=trunk --tags=tags Goldie
> ...the first few revisions (out of 557 total) here...
> r85 = 60d792abf9957f41f70d7ae399fee7ecda0b66f1 (refs/remotes/svn/trunk)
>          M       README.txt
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))

If --preserve-empty-dir isn't working, can't you add these directories after you've cloned the repository?

BTW is a could page about git and svn: http://www.viget.com/extend/effectively-using-git-with-subversion/

-- 
/Jacob Carlborg
January 13, 2012
On 2012-01-13 04:32, Nick Sabalausky wrote:
> I apologize for going so far offtopic with this. But I've taken this to the
> git mailing list, and after working on it for days it's still not working
> and I'm just about pulling my hair out. What makes it even more frustrating
> is that when I attempted SVN->Hg and SVN->Bzr, those were even *more*
> problematic (especially Bzr).
>
> I know DMD made the switch from SVN to Git at one point, so I'm hoping
> someone here might be able to help out before I finally go nuts:
>
> Summary:
> --------------
>
> I'm trying to use "git svn clone --preserve-empty-dirs ..." (Git v1.7.8.3,
> Linux) but after it gets through only a fraction of the revisions, it just
> bails with some cryptic:
>
> On one SVN repo:
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
>
> On the other SVN repo:
> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
> ((?-xism:^trunk(/|$)))
>
>
> The Full Picture:
> -------------------------
>
> I want to convert these to Git:
>
> http://svn.dsource.org/projects/semitwist
> http://svn.dsource.org/projects/goldie
>
> Notes:
>
> - Goldie has some tags.
> - Neither repo has branches.
> - Being SVN, I wasn't shy about including required empty dirs in the repo
> (since every F&*#&$@ filesystem on the G*#$*%^$ planet handles them fine.) I
> need to keep these.
> - For awhile I had been including compiled binaries in the repo. Don't ask
> me why, I just did :) I need to remove these.
> - Obviously not interested in preserving the "downloads" directory (just a
> DSource-ism anyway).
> - Both repos are small enough that known-to-be-slow git-svn should still be
> plenty fast enough for this task.
>
> I did get some help at the git mailing list:
> http://git.661346.n2.nabble.com/SVN-gt-Git-but-with-special-changes-td6840904.html
>
> They showed me how to strip the binaries from the Git repo after it's
> converted (although I haven't gotten that far yet). And I've found some
> tutorials that help out with the author conversions, etc. The problem is
> actually converting the dang repos, and doing it while preserving tags and
> *all* directories (not just the ones that Git's decided are worthy of
> existing). But like I said above, git-svn is just crapping out:
>
> $ git svn clone
> http://svn.dsource.org/projects/semitwist --prefix=svn/ --preserve-empty-dirs -
> -authors-file=semitwistdtools-authors.txt  --trunk=trunk --tags=tags
> SemiTwistDTools
> ...the first few revisions (out of 242 total) here...
> r46 = 61d45b1e70c129a5096bb35686f0d024786c1204 (refs/remotes/svn/trunk)
>          A       cmdTest.pnproj
> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
> ((?-xism:^trunk(/|$)))
>
> $ git svn clone
> http://svn.dsource.org/projects/goldie --prefix=svn/ --preserve-empty-dirs --authors-file=goldie-authors.txt
> --trunk=trunk --tags=tags Goldie
> ...the first few revisions (out of 557 total) here...
> r85 = 60d792abf9957f41f70d7ae399fee7ecda0b66f1 (refs/remotes/svn/trunk)
>          M       README.txt
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
>
>

I managed to clone the semitwist repository using:

git clone -s http://svn.dsource.org/projects/semitwist

"-s" indicates a standard svn layout of the repository.

-- 
/Jacob Carlborg
January 13, 2012
Nick,

On Thu, 2012-01-12 at 22:32 -0500, Nick Sabalausky wrote:
> I apologize for going so far offtopic with this. But I've taken this to the git mailing list, and after working on it for days it's still not working and I'm just about pulling my hair out. What makes it even more frustrating is that when I attempted SVN->Hg and SVN->Bzr, those were even *more* problematic (especially Bzr).

Far from off-topic given the purpose is to work with D-related repositories I would say.

I am surprised you had problems with Mercurial and Bazaar, their support for working with Subversion is very good.

The hgsubversion plugin for Mercurial is excellent and Augie Fackler and the rest of the development folks are helpful and supportive.  A few months ago we switched the SCons repository from Subversion to Mercurial and apart from one thing -- which Augie fixed very quickly -- all the problems turned out to be user error -- which they helped sort out well.

The Bazaar plugin is also excellent:  Jelmer Vernooij has done a great job of ensuring that  that is the case.  All problems I have had with anything to do with this either got fixed by Jelmer ages ago or turned out to be errors in the Subversion repository.

Both these teams will tell you that Subversion is very good at leaving inconsistencies in repositories that the user can never be aware of, but which means that conversion to another system requires hacking.

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

> I know DMD made the switch from SVN to Git at one point, so I'm hoping someone here might be able to help out before I finally go nuts:
> 
> Summary:
> --------------
> 
> I'm trying to use "git svn clone --preserve-empty-dirs ..." (Git v1.7.8.3, Linux) but after it gets through only a fraction of the revisions, it just bails with some cryptic:

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.

> 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?  If so I would just give up and live with the fact that Git doesn't understand directories only files.

> 
> The Full Picture:
> -------------------------
> 
> I want to convert these to Git:
> 
> http://svn.dsource.org/projects/semitwist http://svn.dsource.org/projects/goldie
> 
> Notes:
> 
> - Goldie has some tags.
> - Neither repo has branches.
> - Being SVN, I wasn't shy about including required empty dirs in the repo
> (since every F&*#&$@ filesystem on the G*#$*%^$ planet handles them fine.) I
> need to keep these.

Subversion is not a version control system, it is a versioned filestore that can be used for version control.  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.

> - For awhile I had been including compiled binaries in the repo. Don't ask me why, I just did :) I need to remove these.

--ignore-paths ?

> - Obviously not interested in preserving the "downloads" directory (just a DSource-ism anyway).

--ignore-paths?

> - Both repos are small enough that known-to-be-slow git-svn should still be plenty fast enough for this task.

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.

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.

> I did get some help at the git mailing list: http://git.661346.n2.nabble.com/SVN-gt-Git-but-with-special-changes-td6840904.html
> 
> They showed me how to strip the binaries from the Git repo after it's converted (although I haven't gotten that far yet). And I've found some tutorials that help out with the author conversions, etc. The problem is actually converting the dang repos, and doing it while preserving tags and *all* directories (not just the ones that Git's decided are worthy of existing). But like I said above, git-svn is just crapping out:
> 
> $ git svn clone
> http://svn.dsource.org/projects/semitwist --prefix=svn/ --preserve-empty-dirs -
> -authors-file=semitwistdtools-authors.txt  --trunk=trunk --tags=tags
> SemiTwistDTools
> ...the first few revisions (out of 242 total) here...
> r46 = 61d45b1e70c129a5096bb35686f0d024786c1204 (refs/remotes/svn/trunk)
>         A       cmdTest.pnproj
> Failed to strip path 'src/nonFatalAssertTest/.gitignore'
> ((?-xism:^trunk(/|$)))
> 
> $ git svn clone
> http://svn.dsource.org/projects/goldie --prefix=svn/ --preserve-empty-dirs --authors-file=goldie-authors.txt
> --trunk=trunk --tags=tags Goldie
> ...the first few revisions (out of 557 total) here...
> r85 = 60d792abf9957f41f70d7ae399fee7ecda0b66f1 (refs/remotes/svn/trunk)
>         M       README.txt
> Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
> 

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.

I hope this helps.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 13, 2012
"Jacob Carlborg" <doob@me.com> wrote in message news:jeont0$1bkp$1@digitalmars.com...
>
> If --preserve-empty-dir isn't working, can't you add these directories after you've cloned the repository?
>

I suppose it might be possible since git seems to be big on allowing history rewrites, but I know next-to-nothing about how to actually do it :/

(Doing anything fancy like that in git seems to require deep under-the-hood knowledge of git, and I'm more interested in just using the stupid thing...Argh...)

> BTW is a could page about git and svn: http://www.viget.com/extend/effectively-using-git-with-subversion/
>

Thanks. That's nice, but it seems to just handwave-away the matter of missing directories. Doesn't address it.

> I managed to clone the semitwist repository using:
>
> git clone -s http://svn.dsource.org/projects/semitwist
>
> "-s" indicates a standard svn layout of the repository.
>

Does it still work if you give it --preserve-empty-dirs? (and yea, it seems to work for me too as long as I omit that switch and allow it to throw away my dirs at its discretion...)

It did occur to me though, that I have to strip out the executable files *before* converting the repo, not after, because if I do it after that could lead to more empty dirs which git would likely just throw away again. I did manage to create an SVN clone of the repos on my system with those executble files removed (thanks to svnadmin and svndumpsanitizer: http://miria.linuxmaniac.net/svndumpsanitizer/  (svndumpfilter didn't work, naturally) ), now just need to get git-svn to work right... :/

I discovered by accident that if I run the "git-svn clone..." command again after it bails, it will *appear* to continue where it left off. But unfortunately, that doesn't help because then only *some* of the empty dirs are preserved in the resulting Git repo.


January 13, 2012
"Russel Winder" <russel@russel.org.uk> wrote in message news:mailman.305.1326443113.16222.digitalmars-d@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... ;)


January 13, 2012
Nick,

Atlassian have documented so of their conversion hassles...

http://blogs.atlassian.com/2012/01/moving-confluence-from-subversion-to-git/

mayhap some pointers?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 13, 2012
On Fri, 2012-01-13 at 04:53 -0500, Nick Sabalausky wrote: [...]
> 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.

Mercurial is a bit like Git in not liking empty directories so I am not entirely surprised by the reaction.

> 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.

This I find surprising, but I don't use Windows.  I think Bazaar is definitely moving towards the "only Canonical and GNU use it" end leaving Mercurial and Git as the clear market leaders.  This is sad in a way since Bazaar is distinctly different from Git and Mercurial and has some serious USP in some workflows and contexts.

> 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

Zero responses to the latter two is clearly not good.  I think though it is an indication that fewer people are using Bazaar and Launchpad unless they are Canonical folk working on Ubuntu.

The Bazaar team have responded to the bug report though.

The real place to ask questions is on the mailing list bazaar@lists.ubuntu.com.  This used to be a fairly frantic place, but is now fairly quiet.  Another reflection that Bazaar is less and less at the forefront of DVCS.

> (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.)

I am not sure the Bazaar<->Mercurial bridge has been properly completed. If you need it ask Jelmer directly, and he will surely know.

[...]
> 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.)

<blatant-ad>
All SCons activity is now focusing on Mercurial and BitBucket in case
anyone is interested in helping out with the D support.
</blatant-ad>

[...]
> >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 ;)

Mostly so am I, sometimes it's best just to let it go.

[...]
> 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.

Your experience and mine are very different, I always found the Bazaar support top notch.  Bazaar is still though very much third in the DVCS arena and so increasingly not relevant.

[...]
> 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 :/

Almost certainly best to do all the history editing in Subversion before doing the conversions.

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

Or some other name such
as .dummyfiletokeepgithappywithemptydirectories :-)

[...]
> 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. :/

Hummm... to date I have never had git-svn fail on a standard Subversion structure repository unless there were faults in the Subversion history.

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

On the up side Git has remote tracking branches which are really splendid.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 13, 2012
On 2012-01-13 10:04, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jeont0$1bkp$1@digitalmars.com...
>>
>> If --preserve-empty-dir isn't working, can't you add these directories
>> after you've cloned the repository?
>>
>
> I suppose it might be possible since git seems to be big on allowing history
> rewrites, but I know next-to-nothing about how to actually do it :/

I see no reason to rewrite the history. Just clone the svn repository, add the missing directories, add a .gitignore file to each of the directories so git will keep them and then make a new commit.

> (Doing anything fancy like that in git seems to require deep under-the-hood
> knowledge of git, and I'm more interested in just using the stupid
> thing...Argh...)
>
>> BTW is a could page about git and svn:
>> http://www.viget.com/extend/effectively-using-git-with-subversion/
>>
>
> Thanks. That's nice, but it seems to just handwave-away the matter of
> missing directories. Doesn't address it.

Yeah, it's just a good page describing how to use git for a svn repository.

>> I managed to clone the semitwist repository using:
>>
>> git clone -s http://svn.dsource.org/projects/semitwist
>>
>> "-s" indicates a standard svn layout of the repository.
>>
>
> Does it still work if you give it --preserve-empty-dirs? (and yea, it seems
> to work for me too as long as I omit that switch and allow it to throw away
> my dirs at its discretion...)

It seems I don't have that option.

-- 
/Jacob Carlborg
« First   ‹ Prev
1 2