William Uther <will+@cs.cmu.edu> writes:
> If I were to make a patch that had svn record merge history, but not
> use it, would it have any chance of being applied? It seems like a
> small change with little chance of breaking anything. (Someone
> previously mentioned that they would be -1 on a patch for the whole
> repeated merge thing before 1.0 because there wouldn't be time to
> discuss it properly. I think the data you need to store is actually
> pretty simple and wouldn't need much discussion - it is the easy half
> of the problem. It could always be converted later anyway.)
I hadn't thought it was all that simple; if it turns out it is, we
should kick ourselves that we haven't been storing it all along :-).
> Anyway here is a proposed format:
>
> When you merge data into a file, the merge occurs normally except for
> the svn:merge property. The svn:merge property is not merged, but
> instead a single line is appended to it:
>
> rev-A URL-A rev-B URL-B
>
> rev-A is the start rev of the merge (or * if this is an 'add with
> history' merge - the file didn't exist in revA)
> URL-A is the start URL of the file that was merged (this is a * if
> rev-A
> is a *)
> rev-B is the end rev of the merge
> URL-B is the end URL of the file that was merged (use relative URLs so
> that, if the repos moves, nothing breaks)
>
> There is one detail that I think is important: If merge copies a
> directory that didn't exist in revA (ie the dir was added with
> history) then you want to add the merge property to each file
> individually. This does not affect the time complexity as all those
> files are being copied into your working copy anyway.
>
> This is storing all the information passed on the command line, so I
> don't think it leaves out any information.
Golly.
That's pretty simple. But I can't see anything wrong with it -- at
the very worst, it preserves too much information (or rather fails to
compress information), but we can always deal with that later.
Thoughts, folks? Brane, GregH? :-)
And it's nice that the value can be edited by hand. If Subversion
doesn't understand the full implications of some local edits, the user
can patch up the property if necessary.
I have one concern: Sure, we can use relative URLs so that the repos
doesn't break, but then we're not preserving information that might be
useful to support cross-repository merge history later on. (Of
course, "host.domain/path" is a pretty poor global unique identifier
for repositories anyway, so I'm not saying this feature was ready for
prime time or anything). This isn't a showstopper: for one thing, if
we ever _do_ support cross-repository stuff, we can teach clients to
patch up old format svn:merge properties...
BUT, maybe this tells us a format version number at the beginning of
the property would be good. So the first line would be
"merge history format version: 1\n"
or something, then the rest of the value would be as you describe.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 19:03:04 2002