On Sunday 30 April 2006 03:30, Giovanni Bajo wrote:
> 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.
IMO we might need (and should, to facilitate cross-repo merging later) to give
every revision some kind of uuid, that can be replicated along with the data,
and doesn't change like the revision number.
That would solve the problem of the unknown-revision-number on commit, too.
(If I mirror some repository with svk, I get completely different revision
numbers).
Note: this uuids could be done even now, by a simple perl/python/shell script
or whatever. Repository dump/load is not required.
But that would bring us the other mentioned problem: Huge lists of merged
revisions.
Here it might be necessary to store *not* the list, but a kind of tree -
"I merged all that was included in uuid A, and got revision uuid B down do
uuid D too".
I'll try to paint that.
I'll include the uuids in (). Uppercase letters stand for the result,
lowercase for other changes in this revision *only*.
/trunk /branch
R1 (A) --copy------> R2 (A)
doing changes ...
R2 (C=A+c) R4 (D=A+d)
R5 (E=C+e) R6 (F=D+f)
R7 (G=E+g) /
merging: /
R8 (H=G+F+h) <--merge-/
+h is neede if small fixes/conflicts have to be resolved.
The obvious problem for that is that the merger (client or server) has to
traverse the tree (or even graph!) until a common revision (A in this case)
is found. But that'll happen always, I believe...
If we unmerge (reverse-merge) a revision, we'd have to log a eh. I=H-e or some
such ...
The storing of the "calculation" saves space, but needs a kind of arithmetic
processing before merging.
Just my €0.02.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 2 09:11:44 2006