www.digitalmars.com         C & C++   DMDScript  

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

reply "Nick Sabalausky" <a a.a> writes:
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 

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(/|$)))
Jan 12 2012
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Jan 12 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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

 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
Jan 12 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

 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
Jan 12 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jan 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 13 2012
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-01-13 12:12:09 +0000, Jacob Carlborg <doob me.com> said:


 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.


But if you do that you won't have .gitignore files in all the SVN 
revisions you fetched, so older revisions will be broken.

What can be done is add the .gitignore files to all the revisions, like this:

	git filter-branch -f --tree-filter 'mkdir -p directory; touch 
directory/.gitignore' -- --all

Of course this will add the directory to all commits in all the 
branches of the repository, whether or not the directory was present in 
the SVN repository.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 13 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-13 14:35, Michel Fortin wrote:

 On 2012-01-13 12:12:09 +0000, Jacob Carlborg <doob me.com> said:


 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.


 But if you do that you won't have .gitignore files in all the SVN
 revisions you fetched, so older revisions will be broken.


True, didn't think of that.


 What can be done is add the .gitignore files to all the revisions, like
 this:

 git filter-branch -f --tree-filter 'mkdir -p directory; touch
 directory/.gitignore' -- --all

 Of course this will add the directory to all commits in all the branches
 of the repository, whether or not the directory was present in the SVN
 repository.


There's always a problem :)

-- 
/Jacob Carlborg
Jan 13 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:jepbuq$2m7c$1 digitalmars.com...

 On 2012-01-13 12:12:09 +0000, Jacob Carlborg <doob me.com> said:


 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.


 But if you do that you won't have .gitignore files in all the SVN 
 revisions you fetched, so older revisions will be broken.

 What can be done is add the .gitignore files to all the revisions, like 
 this:

 git filter-branch -f --tree-filter 'mkdir -p directory; touch 
 directory/.gitignore' -- --all

 Of course this will add the directory to all commits in all the branches 
 of the repository, whether or not the directory was present in the SVN 
 repository.


Ahh, now I like that! It does, of course, mean that old revisions will be 
cluttered with unnesessary hidden files, and I'll need a commit to get rid 
of them going forward, but that's a *lot* better than the other way around 
(leaving them missing in the history and then adding them after the fact). 
"Works for me." I'll try it...
Jan 13 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jep72q$2dvs$1 digitalmars.com...

 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.


Yea, like Michel said, that leaves the old revisions broken.


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


It is, thanks.


 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.


I'm told it was added in Git v1.7.7. I had to compile a fresh git from 
source (although that might just be because I spent the last two years 
*completely* misunderstanding "apt-get upgrade"...and I think I have 
legitimate excuses for misunderstanding it, but that's a whole other 
topic...I plan to write a mini article-rant on it...)
Jan 13 2012
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jeq72b$19me$1 digitalmars.com...

 (although that might just be because I spent the last two years 
 *completely* misunderstanding "apt-get upgrade"...and I think I have 
 legitimate excuses for misunderstanding it, but that's a whole other 
 topic...I plan to write a mini article-rant on it...)


https://www.semitwist.com/articles/article/view/doesn-t-anyone-understand-proper-usability-design
Jan 14 2012
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
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 t=


he=20

 git mailing list, and after working on it for days it's still not working=


=20

 and I'm just about pulling my hair out. What makes it even more frustrati=


ng=20

 is that when I attempted SVN->Hg and SVN->Bzr, those were even *more*=20
 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?=20


 I know DMD made the switch from SVN to Git at one point, so I'm hoping=


=20

 someone here might be able to help out before I finally go nuts:
=20
 Summary:
 --------------
=20
 I'm trying to use "git svn clone --preserve-empty-dirs ..." (Git v1.7.8.3=


,=20

 Linux) but after it gets through only a fraction of the revisions, it jus=


t=20

 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'=20
 ((?-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.


=20
 The Full Picture:
 -------------------------
=20
 I want to convert these to Git:
=20
 http://svn.dsource.org/projects/semitwist
 http://svn.dsource.org/projects/goldie
=20
 Notes:
=20
 - Goldie has some tags.
 - Neither repo has branches.
 - Being SVN, I wasn't shy about including required empty dirs in the repo=


=20




) I=20

 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 as=


k=20

 me why, I just did :) I need to remove these.


--ignore-paths ?


 - Obviously not interested in preserving the "downloads" directory (just =


a=20

 DSource-ism anyway).


--ignore-paths?


 - Both repos are small enough that known-to-be-slow git-svn should still =


be=20

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

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-td684=


0904.html

=20
 They showed me how to strip the binaries from the Git repo after it's=20
 converted (although I haven't gotten that far yet). And I've found some=


=20

 tutorials that help out with the author conversions, etc. The problem is=


=20

 actually converting the dang repos, and doing it while preserving tags an=


d=20

 *all* directories (not just the ones that Git's decided are worthy of=20
 existing). But like I said above, git-svn is just crapping out:
=20
 $ git svn clone=20
 http://svn.dsource.org/projects/semitwist --prefix=3Dsvn/ --preserve-empt=


y-dirs -=20

 -authors-file=3Dsemitwistdtools-authors.txt  --trunk=3Dtrunk --tags=3Dtag=


s=20

 SemiTwistDTools
 ...the first few revisions (out of 242 total) here...
 r46 =3D 61d45b1e70c129a5096bb35686f0d024786c1204 (refs/remotes/svn/trunk)
         A       cmdTest.pnproj
 Failed to strip path 'src/nonFatalAssertTest/.gitignore'=20
 ((?-xism:^trunk(/|$)))
=20
 $ git svn clone=20
 http://svn.dsource.org/projects/goldie --prefix=3Dsvn/ --preserve-empty-d=


irs --authors-file=3Dgoldie-authors.txt  =20

 --trunk=3Dtrunk --tags=3Dtags Goldie
 ...the first few revisions (out of 557 total) here...
 r85 =3D 60d792abf9957f41f70d7ae399fee7ecda0b66f1 (refs/remotes/svn/trunk)
         M       README.txt
 Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
=20


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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jan 13 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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... ;)
Jan 13 2012
parent Russel Winder <russel russel.org.uk> writes:
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=


=20

 basically told me that I was wrong for wanting to preserve the empty=20
 directories that the buildsystem for those old revisions was relying on. =


And=20

 they also said that none of the hg/svn tools had any option for inserting=


=20

 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:
=20
 I was actually completely sold on going with Bazaar at first. But  first =


of=20

 all, *none* of the conversion scripts even *ran*. *At all*. Every single =


one=20

 I tried would just crash right out the gate no matter what arguments I ga=


ve=20

 them (or even no args, or --help, etc...). And so I tried Bazaar's Python=


=20

 installer, and *that* just kept crashing! Yes, the installer. Someone=20
 directed me to try a different version, but the links to it were broken! =


It=20

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


 And on top of that, I spent hours trying to find the correct place to ask=


=20

 about it all (so if I did manage to ask in the wrong place, it sure as he=


ll=20

 wasn't for lack of trying). I got two meaningful repies (and one complete=


ly=20

 useless one) to *one* of the posts I made, and they ended up not helping =


at=20

 all. My other posts just *sat* there for literally *months* with *zero*=


=20

 responses. Here's the posts:
=20
 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=20

 my less important Hg repos to Bzr so I could try out Bzr on one of my=20
 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=


,=20

 and the fact that I like TortoiseGit much better than TortoiseHg (And=20
 because bitbucket now supports Git. If GitHub were my only Git option, I'=


d=20

 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.


=20
 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 t=


he=20

 complete lack of support, and the lack of half of it even working at all,=


=20

 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=20
 svndumpsanitizer: http://miria.linuxmaniac.net/svndumpsanitizer/ ) to rem=


ove=20

 the executable files.
=20
 Maybe I should try removing the downloads dir too...But now I'm just taki=


ng=20

 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=


=20

 before git even touches it?


Or some other name such
as .dummyfiletokeepgithappywithemptydirectories :-)

[...]

 Yea, it is the usual structure (aside from the additional top-level=20
 downloads directory). And I included "--trunk=3Dtrunk --tags=3Dtags" (the=


re are=20

 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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jan 13 2012
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Nick,

Atlassian have documented so of their conversion hassles...

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

mayhap some pointers?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jan 13 2012
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-01-13 03:32:25 +0000, "Nick Sabalausky" <a a.a> said:


 $ 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(/|$)))


You can fix yourself the git-svn script if you want:
<https://github.com/git/git/blob/master/git-svn.perl>

To me it seems like the git_path sub is called on an already stripped 
path. It would probably just work if you just removed the 'die' command 
on line 4583 of git-svn, even though that's a dirty fix. (Line number 
taken from github's master, you might be using a different version.)



-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 13 2012
parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:jeph56$bl$1 digitalmars.com...

 On 2012-01-13 03:32:25 +0000, "Nick Sabalausky" <a a.a> said:


 $ 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(/|$)))


 You can fix yourself the git-svn script if you want:
 <https://github.com/git/git/blob/master/git-svn.perl>

 To me it seems like the git_path sub is called on an already stripped 
 path. It would probably just work if you just removed the 'die' command on 
 line 4583 of git-svn, even though that's a dirty fix. (Line number taken 
 from github's master, you might be using a different version.)


http://www.semitwist.com/download/av/sumomo-correct-confetti.avi

I went to that line in the git sources, changed "die" to "print", "make && 
sudo make install", and it works!

It doesn't, however, delete directories once they actually *are* deleted in 
the SVN repo, which is rather sloppy, but I can at least live with that.
Jan 13 2012
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
Nick, I had similar issues, and I solved them by following a 
recipe from this article (written by a GitHub developer): 
http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/

I still believe Subversion is a very good VCS.
Jan 13 2012
parent "Nick Sabalausky" <a a.a> writes:
"Dejan Lekic" <dejan.lekic gmail.com> wrote in message 
news:nlcegzzpmmfrgaljgzkh dfeed.kimsufi.thecybershadow.net...

 Nick, I had similar issues, and I solved them by following a recipe from 
 this article (written by a GitHub developer): 
 http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/

 I still believe Subversion is a very good VCS.


Yes. You know, I've been wanting to do a little write-up of "Why I'm 
completely sold on DVCSes, but I was happier before them" :) And I still get 
annoyed when Torvalds rants and whines about SVN (has Linus *never* had to 
use Visual SourceSafe?) I also like that SVN seems to genuinely care about 
binary data/asset files (hugely important for things like games).

Admittedly, there was one big problem I did have with subversion: Every time 
I needed to move or rename a directory tree, subversion completely choked on 
it, and it was a PITA to fix the working copy. It's *extremely* brittle with 
that kind of change, you have to do it *exactly* right. Eventually I got 
into the habit of breaking the whole operation into carefully-chosen 
multiple committs, which seemed to help, but always felt "dirty", and I 
always dreaded doing it.
Jan 13 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
Now that I've gotten it worked out, I've put up an article with my complete 
notes on the whole process in case anyone's interested or needs help doing 
the same thing:

https://www.semitwist.com/articles/article/view/the-better-svn-git-guide
Feb 05 2012