> 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".
Ah! But that's why a definition needs to be written. As soon as the
definition is ready, the 'right' way to do it can be determined.
> 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 :)
Actually, no. It was pushed back from 1.0, because delaying 1.0 for two
more years (for locking, true renames and mergetracking) would have been
insane. Both the client and server were fully functional at production
quality level and self-hosting for over 4 years. It would have been plain
stupid not to offer the 1.0 release: people were waiting for it.
Some people just were not allowed to use it because of policy: they needed
full production quality software: they could not introduce Subversion with
their employers under the 0.27 number label...
As you can see, there's much more to a 1.0 release than merge tracking.
> > 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.
Which is great! If we watch closely what experience they accumulate, we
will be able to implement our merge tracking hopefully without any of the
problems they are currently experiencing (if any).
> > 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.
Well, I can only re-iterate what Branko said: if you don't know how you'll
be using the information stored, then you really can't decide on a good
design.
> 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.
Which is why we think it's better to do a *design* before starting to record
anything which might turn out not-usefull...
> >> 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".
We do that. The only thing is that we were pointing out that the first step
is the *definition* of merge tracking, not the recording of something
somewhere.
> 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.
Sure. Ben Collins-Sussman already mailed Carl (and the list) that if he is
serious in persuing merge tracking, then there are several steps. He didn't
say that he had to stop here and now.
History has learned us that submitting patches before a design does not work
with the Subversion dev community. (Which I consider a good thing!)
> 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.
If you need information to be recorded, then why don't you use svnmerge
which does exactly this for you? There's no need to have that in the svn
core binary (yet): as soon as merge tracking has been implemented, *then* it
might be required by the core binary.
> Maybe Carl's proposal could be named "merge noting", and possibly
> reconsidered seperatly?
No. He can help merge tracking off the ground by writing definitions and
designs (before patches). If you need 'merge noting', there's svnmerge or
svk.
Bye,
Erik.
PS: Sorry to be so strict, but it's part of why svn is able to maintain such
a high quality standard...
--
Handyrechnung zu hoch? Tipp: SMS und MMS mit GMX
Seien Sie so frei: Alle Infos unter http://www.gmx.net/de/go/freesms
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 16:50:55 2005