Branko Čibej <brane@xbc.nu> writes:
> 1. store the URL+revision of each merge source in the target file's
> props (and /visa versa/)
> Pros: The info is independent of the FS implementation.
> Cons: It's very verbose, and potentially eats a lot of space.
> 2. store the same info in the node FS as a list of (source/target)
> node IDs
> Pros: Compact representation, doesn't eat space in the WC
> Cons: Depends on the FS implementation; the client must
> specifically request the info to get it (that might actually be a
> pro, who knows)
> 3. make a new kind of record in the database a "merge association",
> indexed by source and target node ID.
> Pros: Compact representation, and lots of metadata could be tagged
> on to the merge record
> Cons: Basically same as (2)
>
> (Each of these possibilities has several variations, but that's the
> basic idea.)
>
> Fishing for comments ...
I like #1 the best, becuase it's "con" is actually not so bad, and it
puts the information firmly on the client side, where the client can
decide how to use it. Merge policy *is* the client's problem, after
all -- a client may decide to get the changes anyway and do something
with them, or not get them, or anything in between. I don't think the
client should need to contact the repository to discover the merge
history. If it can get it locally, it may even discover that there's
nothing to merge, without doing a network turnaround.
The information in the common case compresses very well, too. For
example, people usually merge from the same branch(es) multiple times.
That might be stored on trunk/parser/sexps.c as a property value like
this:
"{http://svn.foo.com/repos/branches/dev/parser/sexps.c:17,20,25-31,45}"
...meaning that trunk/parser/sexps.c has received merges of the
following changes from /branches/dev/parser/sexps.c:
16-->17
19-->20
24-->25
25-->26
26-->27
27-->28
28-->29
29-->30
30-->31
44-->45
(Note how a revision number means "the change introduced in that
revision".)
Every time we see an opportunity to collapse a sequence into a range,
we take it. I really doubt that the value of this property would get
very big, for most files. But don't ask me to be precise about "very
big". :-)
I do think it should be a regular property, not an entries property.
There are lots of scenarios where hand-editing the property's value
would be a useful thing.
By the way, regardless of when we start *using* the information, we
should start storing it right away, +1 on that.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006