[SVNMERGE][PATCH] svnmerge rollback

Archie Cobbs archie at dellroad.org
Fri May 19 12:22:11 PDT 2006


Madan U Sreenivasan wrote:
> I second Giovanni, we need to internally only maintain N-REV as the  
> svnmerge-integrated property, where N is the branch creation revision.
> It will help us intrinsically maintain the revision at which the source  
> was created without having to query for it everytime.
> 
>> This doesn't seem right. It seems like you'd be changing the semantics
>> of the property. Revisions 1-N have in fact been merged, albeit  
>> trivially.
> 
> Right, so the display_revision() functions should *understand* N-REV as  
> 1-REV and display hence.
> The user always sees 1-REV as the integrated revision range. This would  
> not change.

OK, that's good.

>> If you just need to avoid an svn call, why not instead record the first
>> revision "N" explicitly as an additional bit of information.
> 
> nah, store N-REV. Why some extra bytes?
> 
>> Either way, you'll need compatibility and upgrade code, but the latter
>> approach seems cleaner and more consistent.
> 
> Giovanni's detect 1-REV style and silently change it to N-REV sounds a  
> good approach to me.

Here's the slight advantage changing the format has (seems to me):
first, any other tools which look at this property will not no about
this change, and might possibly break silently. Better to change the
format and break them loudly :-)

Similarly, what if two people are using different versions of svnmerge,
one before your change and one after? The older version is going to
make a mess of things because it doesn't know about the change. Better
to make it fail with a "can't parse revision property" error instead
of e.g. bogusly trying to merge revisions 1-N.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com



More information about the Svnmerge mailing list