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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 19 21:23:56 2006