John Peacock wrote:
> Daniel Berlin wrote:
>> solo turn wrote:
>>> as the only possibility to solve that problem up to now was svk, and i
>>> guess many people know svk: what is the difference between svk and
>>> your proposal?
>> In terms of what?
>> My proposal is simply a design for storing the merge information.
>> Nothing more, nothing less.
>
> I was also wondering how your proposal differs from how SVK is currently storing
> merge information. I realize that your proposal doesn't include SVK's multiple
> merge methodologies (star-merge, cherry-picking, and, just recently added to
> trunk, interactive commit).
My proposal includes *no* merge methodologies, only the means to support
them. And it will support all of those.
But there are already merge tags in Subversion's
> own repository that originate from SVK commits. How are those tags going to
> interoperate with your proposed tags?
You could write a conversion script trivially.
> What feature of your proposal is superior
> to the existing scheme that SVK has been sucessfully employing for several years
> now?
They are similar, but
1. SVK only stores merge info at the roots
2. SVK keeps the UUID of the repo in the list
The rest of all the differences can be attributed to the fact that SVK
has the entire repo around, and we don't, so we need to be more
efficient on some things.
This part of SVK, more than any other, makes attempting to compare
proposals for storage design somewhat nonsensical, to be honest.
You can compare what merge strategies the support or intend to support,
but AFAIK the answer is "all of them".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 10 02:44:03 2006