[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: SVN Branch Description Format
From:       Andrew Sayers <andrew-git () pileofstuff ! org>
Date:       2012-03-31 1:27:59
Message-ID: 4F765D9F.70404 () pileofstuff ! org
[Download RAW message or body]

On 30/03/12 05:06, Ramkumar Ramachandra wrote:
> Hi,
> 
> Andrew Sayers wrote:
>> SVN Branch Description Format v0.1
> 
> I found this pretty interesting.  Doesn't it duplicate some of the
> functionality of reposurgeon [1] though?
> 
> [1]: http://esr.ibiblio.org/?p=4071

Yes, I've been procrastinating all week instead of reading up on
reposurgeon and contacting ESR about possibile collaboration.

I think you need something a bit more expressive than reposurgeon's
format to do SVN<->Git conversion well, and I think you need something a
bit more accessible in order to document SVN edge cases.  For example, I
don't see how reposurgeon could represent all the madness around SVN
cherry-picks that become merges when you manually add information from
revision logs, then become cherry-picks again when you find a revert
coming in from another branch.  Having said that, a (lossy) conversion
between SBL and reposurgeon format would probably be useful and not that
hard.

The link above put it very well that most people leave an embarrassed
"to be done" comment and disappear when they realise how much of a
nightmare the mapping is.  What it doesn't mention is that everyone
experiences a slightly different part of the nightmare, and that we can
only really tackle the problem by getting everyone's freaky edge cases
written up in one language in one place.  The test suite[1] isn't that
impressive right now, but in the long-term I'm really keen to get
implementers to pool their knowledge so we can all benefit.  SBL is
designed to let people open the relevant test without reading the spec
and say "oh right I understand what a piecemeal merge is now.  I'll go
implement that in my project".

I'm currently working on code to read an SVN dump and write to SBL.
This will definitely overlap with reposurgeon's SVN export
functionality, but without seeing the final code I can't say how much.
That's fine though - as I say, the only way to get a good solution is
for multiple implementers to investigate the problem and share the edge
cases they find.

	- Andrew

[1]https://github.com/andrew-sayers/SVN-Branching-Language/tree/master/t
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]