I will post the revised document. In the meanwhile, here are answers to
some of the open ended questions you have asked.
> It would be informative to apply this algorithm to the merges that have already
> been done on Subversion's repository, to see what the result is. For instance,
> that might give a reasonable indication of whether the lists of revisions are
> going to grow too long to be considered human-usable, as someone wondered.
I did before i started, and the list of revisions doesn't grow that long
(It's about 20-30 revisions).
However, there is simply nothing you can do about this.
Human editing was meant to fix merge info for changes you have made that
will affect it that subversion doesn't know about, not to do anything
else. This generally consists of removing a merged rev, adding one, or
splitting one. None of these require anything more than looking up a
specific number or range in the merge info, and doing the right thing to
it, so i can't see how, even if the list was 100k revisions long (and
sorted), how this would not be "human usable".
What do you forsee humans doing to it that requires actually caring
about all 100k revisions in the list?
> > Information storage
> >
> > The first question that many people ask is "where should we store the
> > merge information" (what we store will be covered next).
>
> Well, they may ask, but it doesn't make much sense to discuss this until we
> know what information is to be stored.
Actually, this is wrong in this case, even if it may be true in general.
How you store the merge info will generally dictate what you can store,
for performance and space reasons. Thus, it makes perfect sense to
specify how you store it first.
> I half-understood that some parents/grandparents might store copies of the
> merge info that is on this object. If so, and if you don't explicitly remove
> the other copies of this info from the parent dir(s), won't obsolete history
> build up, that is not incorrect but is annoying?
Yes, obsolete info can build up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 5 18:39:47 2006