Re: Merge tracking

Branko ÄŒibej wrote:

It is the fate of usefull tools to be *just* short of being a usefull
tool for something bigger, so here i am with my hat in my hand :)

>> Is the choice really between "the grand solution" and "nothing"?
> No, the choice is beteween "right solution" and "nothing".

Noone knows what "merge-tracking" is, much less what is "right".

That explains why it was pushed back from 1.0 and now into "Medium-term
Goals", and doesn't really seem to have any chance of being done anytime
soon :)

> Jumping into the code and making that small step that seems "obvious" is
> a recipe for disaster. We've tried it before and got burned (the WC is a
> good example).

Demands on WC has grown, and outgrown it's design. I can point to many
things that would be nice, or could be better, but the nicest of all is
that at least *something* is there.

It's important to get things right, but it's also important to
experiment in order to be able to *be* right. Svk and svnmerge are
experimenting (with success) and are going in the same direction.

> WRT this specific solution: until you've thought out the big picture,
> you can't be sure that the recorded operations and "standard" format are
> what you'll actually need.

The proposal was to simply record all the revision-information that went
into "svn merge" (resolved, of course). You can replay the merge from
the information recorded.

Where it should be recorded can be discussed, and that obviously needs
to be done. But what would really make a difference is if it was just
recorded somewhere.

For the time being that is manually, and in the comments, and people
live with that for now, so it's not the end of the world.

>> No matter what the discussion on
>> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt ends up
>> with, this is valuable information to have available.

> But only if it actually turns out to be useful. Please, let's do this
> the right way. We don't want to get ourselves into the situation (again)
> where we have a half-baked solution that doesn't meet our needs, and yet
> have to keep it around for ages because of our compatibility policy.

I can see the point in that argument, but please let someone take a
first little step towards recording merge-information, even though it is
related to "merge-tracking".

I understand the timing is a bit off, since SVN is focusing on 1.2, but
I'd like to get Carl's proposal marked at least for due consideration
when the time comes.

Especially since it is small, usefull in it's own right (independant of
"merge-tracking") and has a very high probablility of being a
building-block for the "right solution" (judging by svk & svnmerge). It
can certanly shed some light on what is important for "merge-tracking"
to emerge, without introducing anything but a protocol on
property/rev-property.

Maybe Carl's proposal could be named "merge noting", and possibly
reconsidered seperatly?

-- 
Helge Jensen
   mailto:helge.jensen@slog.dk
   sip:helge.jensen@slog.dk
                -=> Sebastian cover-music: http://ungdomshus.nu <=-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org