Daniel Berlin <dberlin@dberlin.org> wrote:
> A merge info property, named SVN_MERGE_PROPERTY (not the real name, I
> have made it a constant so we can have a large bikeshed about what to
> really call it) stored in the revision properties, directory
> properties, and file properties.
My bikeshed is to call it svnmerge-integrated. Not sure if it's possible given
that "svn:" namespace policy, but I'm sure many users will be happy of that.
One thing that I would like to throw in is a problem we face in svnmerge: if
you merge r100 from branch A into B, and the merge is done in a new commit
(r200), there is no way svnmerge can know that r100 and r200 are, effectively,
the same patch, just committed to two different branches. This is of course a
problem if you then merge into branch C, since you should keep track of the
fact that, if r100 is merged, you don't need to merge r200.
svnmerge's problem comes from the fact that it can't know that r200 is going to
be r200 before it is actually committed, so it can't record it into the
property somehow. I believe this should be fixed if the backend handles merge
tracking.
> This is chiefly because the benefit of such a canonical format
> (slightly easier *comparison*, but not indexing) is heavily
> outweighed by the fact that generating a canonical form may require
> groveling through a lot of information to determine what that minimal
> canonical form is. In particular, it may be that the revision list
> "5,7,9" is, in minimal canonical form, "5-9", because 6 and 8 do not
> have any affect on the pathname that 5 and 9 are from.
> Canonicalization could be done as a server side post pass because the
> information is stored in properties.
Notice that this canonicalization is done by svnmerge whenever it comes from
free, which is almost always since it always has to run a svn log to see which
revisions to merge. And when it's parsing the svn log output, it's easy to
notice gaps and use them to canonicalize. If you look at svnmerge code, these
commits to other branches are called "phantom revisions".
Producing a canonicalizes range has one very big benefit, when doing merge
tracking in development branch: it keeps the merge property very small and
readable. Basically, it's always something like "/trunk:1-1000", which is very
easy for the human ("this branch was last merged at r1000"). If you don't do
this, the property gets several kilobytes long after a few months (especially
if you have a large repository with many branches or - worse - many different
projects in it). When you have 10 pages worth of random numbers, it's pretty
hard to know what's going on, and people will go wtf.
In other words, if you don't do canonicalization through phantom revisions,
you're going to miss most of the advantages of using an ASCII property. You can
as well use a binary one at that point.
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 30 03:30:49 2006