Karl Fogel wrote:
>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.
>
I'm leaning that way, too. a) it's the only place where we can store
correct source URLs, not just node ids (paths are important, after all);
b) "svn revert" dtrts for us, every time.
>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". :-)
>
:-) we may want to start compressing stuff in the WC, but that's neither
here nor there.
>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.
>
Yes, that was my point. Even if we don't use it for genetic (read:
magic) merging, it's useful info for the user.
--
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 Sat Oct 21 14:37:00 2006