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
_______________________________________________
Svnmerge mailing list
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
