Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

From: Stephen Bash <bash@genarts.com>
Date: Oct 19, 2010, 14:57 UTC
Message-ID: <28402633.527046.1287500245894.JavaMail.root@mail.hq.genarts.com>
In-Reply-To: <126B270C-AEB2-4632-A2CD-E8F2AAE20A62@cordelta.com>

----- Original Message -----

Show 14 quoted lines

> From: "David Michael Barr" <david.barr@cordelta.com>
> To: "Stephen Bash" <bash@genarts.com>
> Sent: Tuesday, October 19, 2010 10:28:03 AM
> Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)
> 
> So, I think there's two valuable nuggets per commit omitted at the
> moment in svn-fe.
> Firstly, the longest common root between all paths in the commit,
> which can be computed efficiently.
> Secondly, the copyfrom_rev and copyfrom_path for the copy operation
> that targets the common root.
> The second nugget can be noted while computing the first.
> From my reading of buildSVNTree.pl, these two nuggets drive the
> mapping logic.

Yep, they're the triggers, then the heuristics just filter out the noise SVN encourages because of light copies (or cruft from cvs2svn).

Just watch out for svn mv operations.  They produce a single commit with an Add (with copyfrom_* set) and a Delete.  So in the /project -> /trunk/project case, you're common path is /.  I didn't have that case, but I did have a /trunk cp-> /branches/tagName (oops!) mv-> /tags/tagName and a /trunk cp-> /branchName (oops!) mv-> /branches/branchName (honestly I much preferred the cases where the user deleted the wrong location and then created a new copy in the right place -- there are a ton of those which I didn't bother to capture the misstep in the middle).

Thanks, Stephen