Now here is a discussion! Thank you for all of your input.
Let me take a minute to let you get to know me better and make my plans
a little more clear. Hopefully, I can put to rest most of your
concerns. I will respect constraints on time that you have while
working toward other goals and I hope to gain your respect as someone
who wants the right solution and who is bright and technically competent
enough to help come to this solution.
My plan IS/IS NOT...
IS NOT to hack up the code and submit a patch. I plan to write up
design documents with examples and proposed uses of recorded data. I
will submit those to be reviewed and hopefully recorded in the notes
section of the repository. Rest assured that I will not simply submit a
patch and expect it to be prompty integrated.
IS to get hands dirty and play in the code. I have to do this to
understand the problem that I hope to solve. Don't worry, nothing will
be committed until it is right, however long this takes.
IS to consider both svk and svnmerge. Both will help us understand the
problem but I don't believe either has come to a complete solution.
Also, I believe the right belongs integrated with svn merge in order to
be useful. I will expound on this soon in my design proposals.
IS NOT to come into this blind to the general problem of merging. I am
a long time user of the UNIX tools diff,patch,merge and so on. I have
experience with branching/merging in Clearcase which has solved many of
the issues that subversion faces. I have a solid and in-depth
understanding of how its mechanism works. I have written software that
traverses a Clearcase revision tree following merge arrows and branch
points to extract detailed, complete and correct information about which
branches and revisions contribute to a given version. I have also been
an arch user and have a good understanding of the mechanism used there.
In about a week, I hope to have the first draft of a design document, in
text, to post to the list. I will consider svk and svnmerge as well as
the notes in .../svn/trunk/notes/merge-tracking.txt.
Cheers,
Carl
On Wed, Mar 30, 2005 at 04:46:12PM +0200, Erik Huelsmann wrote:
> > 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 19:00:49 2005