Daniel Berlin wrote:
> I will post the revised document. In the meanwhile, here are answers to
> some of the open ended questions you have asked.
Thanks; I've just seen the second revision, but haven't read it properly yet.
>>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).
That's good to hear.
> However, there is simply nothing you can do about this.
On the contrary, the person who talked about 'svnmerge.py' said that it was
able to reduce lists like "1,2,3,4,5" to ranges like "1-5" and even do the same
for lists with gaps where the missing revision numbers were irrelevant to the
target.
[...]
> What do you forsee humans doing to it that requires actually caring
> about all 100k revisions in the list?
I don't know. Simply loading the text into an editor and finding the
appropriate place in the line would fail or take an unreasonably long time with
some editors that have line length limitations or assumptions. OK, you can
blame those editors. Anyway, that was just one aspect to think about.
>>>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.
This is irrelevant to the proposal itself, but it seems we misunderstood each
other. By "what information" I meant information in the abstract, logical
sense, not the particular encoding of it. I meant that you can't choose a
suitable storage location until you know certain things about the data you want
to store - its required lifetime, whether its size is fixed or variable, etc.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 7 11:44:22 2006