David James wrote:
> On 2/12/06, Branko Čibej <brane@xbc.nu> wrote:
>
>> But first of all, you can't just come up with some database schema to
>> "solve merge tracking" without first spelling out the actual problems
>> you're trying to address.
>>
>
> Please see the list of problems below, quoted from
> http://svn.haxx.se/dev/archive-2006-02/0701.shtml
>
>
>> On 2/12/06, David James <djames@collab.net> wrote:
>>
>>> Problem #1: What revisions need to be merged from "trunk" to "branch"?
>>> Problem #2: What branches contain this change?
>>> Problem #3: What branches contain this exact version of this file?
>>> Problem #4: Where has this file been copied?
>>> Problem #5: Is this version of 'foo.c' the latest version? Has this file
>>> perhaps been updated on a branch?
>>>
>
> The above list is by no means a complete list of all the problems that
> merge tracking has to solve. If you've got more ideas as to what merge
> tracking should do, let me know, and I'll incorporate your
> suggestions.
>
The above list is about lots more than just merge tracking. #3, #4 and
#5 are history tracking, for example; history tracking and merge
tracking are related, but they sure aren't the same thing.
>> Second of all, an SVK-like wrapper (with its own database, even) isn't
>> going to solve merge tracking in *Subversion*, however hard you try.
>> This is something we have to solve on the repository and/or client
>> library level, not in some add-on tool.
>>
>
> You're right. If we integrated merge-tracking into the core libraries,
> we'd be done. But, before we do that, I think it'd be a good idea to
> carefully think through what we want to do. For this reason, I think
> it'd be a good idea to put out a prototype design first.
>
What I'm getting at is that a database schema isn't a design. It's part
of a design, and a fairly low-level part at that. You start out with use
cases and requirements (o.k., some of that seems to have been done);
then you define a set of features based on those requirements; then you
see how those features interact with the current set of features, and
with the architecture; *then* you start designing the implementation.
>> Starting on any kind of prototype without doing the necessary design work first
>> is the worst possible thing we could do for SVN, because we're almost guarantee
>> to screw up along the way, and we'd get yet another can of worms to fix in 2.0.
>>
>
> The big benefit of a 'quick prototype' is that, if you screw up, it
> doesn't cost that much -- it's just a prototype!
It costs too much if it's a prototype of something you aren't even
interested in. Sure you can do whatever you want with your time.
> You can start fresh,
> and learn from your mistakes. That said, if you'd like to read a
> detailed design, please read the rest of my email, at:
> http://svn.haxx.se/dev/archive-2006-02/0701.shtml
>
I did. As I said, it doesn't answer basic questions about what you want
to achieve.
Merge tracking is *not* a trivial hack, as I'm sure you're aware. It
would be nice if for once we started off with a sound theoretical model
instead of throwing together yet another matchstick-and-chewing-gum
edifice. We've got enough of those in the code as it is.
Is that too much to ask?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 13 04:52:20 2006