William Uther wrote:
> I'm all for storing more information. There are currently three
> different "log formats": The original, the current, and the one
> described in Issue #820. I think the current format is better than
> the one before the copy-with-history patch. I think the Issue #820
> one is better still (It doesn't lose any information, and adds
> consistency).
>
> To sum up the changes I think we need to make to store merge info (in
> O(1) space):
>
> i) Files that are modified during a merge get a line added to their
> svn:merged property. This stores enough to re-create the command line.
Do you want to just recreate the sequence of merge commands, or just
record enough information to generate _equivalent_ merge commands? Your
solution is sufficient for the first case, but it wastes space in
general. For example:
$ svn merge -r1:4 branch trunk
$ svn merge -r3:7 branch trunk
With your solution, svn:merged on trunk/* would look like this:
branch 1:4
branch 3:7
A more compact representation, that would give the same result (as far
as we know without finer granulation!) would merge those ranges into
branch 1:7
That's what I'd propose: svn:merge contains one line per merge source
(filesystem path, not URL), with a compressed list of relevant ranges.
After a more complex set of merges:
$ svn merge -r1:4 foo trunk
$ svn merge -r3:4 bar trunk
$ svn merge -r3:4 qux trunk
$ svn merge -r7:12 foo trunk
$ svn merge -r4:8 qux trunk
you'd get:
bar 3:4
foo 1:4 7:12
qux 3:8
> ii) Files/Dirs that are copied during a merge get a "merge" line in
> the copies table, not a "copy" line. Pre-1.0 these two could be
> treated identically, although that would change post-1.0. (see
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=19798)
>
> To make part ii) work, the difference between a merge and a copy needs
> to be added to the wire protocol somewhere to get the information back
> to the server, and the dump/load format needs to change to record the
> difference between the two types of copies.
Are you certain that would be enough to "fix" 'svn log' for you? I'm
asking because I don't know the details of how 'svn log' follows copy
history. I certainly don't see a problem with this, but I'd like to see
comments from our Schema King first.
> At the moment I'm waiting to see how issue #838 resolves, because that
> affects how change ii) would be made.
Fixing #838 will involve changing the use of svn_client_copy (back) to
svn_wc_add (with history), for now. Bill Tutt proposed a change in the
way CopyIDs are produced for merges and lazy copies, but that would
entail a pretty big libsvn_fs change, and I'm not sure it's worth it.
Anyway, I fail to see how #838 affects (ii), because the semantics
(e.g., merge does a copy behind the scenes) must remain, IMNSHO.
> Do you still think this is not enough information?
I suppose this could be a workable first step, yes. Care to write the
spec, and implement it? :-)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 00:02:34 2002