You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Carl Baldwin <cn...@fc.hp.com> on 2005/03/15 21:57:30 UTC
Merge tracking
Hello,
I am new to this list. I am also new to subversion but I'm fairly well
acquainted with Version Control with a slew of other systems (cvs, p4,
bk, arch, clearcase).
As I have been looking into subversion I have become very interested in
the possibility of merge tracking.
Where can I go to follow development and discussions on merge tracking?
I am interested in knowing how far along it has come and if there is
anything that I can do to help. I can bring some coding expertise and
experience in creating and traversing version trees with merges.
I would like to see Merge tracking working in subversion and I'm willing
to lend a hand.
Could someone point me some things on this topic? Maybe some specific
threads on the email list or a page on the subversion.tigris.org or
something?
Thank you,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Kevin Puetz <pu...@puetzk.org>.
Carl Baldwin wrote:
> Hello,
>
> I am new to this list. I am also new to subversion but I'm fairly well
> acquainted with Version Control with a slew of other systems (cvs, p4,
> bk, arch, clearcase).
>
> As I have been looking into subversion I have become very interested in
> the possibility of merge tracking.
>
> Where can I go to follow development and discussions on merge tracking?
> I am interested in knowing how far along it has come and if there is
> anything that I can do to help. I can bring some coding expertise and
> experience in creating and traversing version trees with merges.
>
> I would like to see Merge tracking working in subversion and I'm willing
> to lend a hand.
>
> Could someone point me some things on this topic? Maybe some specific
> threads on the email list or a page on the subversion.tigris.org or
> something?
>
> Thank you,
> Carl
I would also look at svnmerge and svk (both of which use the svn core, and
attempt merge tracking through extra data stored in properties).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Carl Baldwin <cn...@fc.hp.com>.
Hello,
Thank you for your response. I'm glad there are some with things to say
about what I'm working on.
I am looking at using the svk property. I understand that there is
value to reusing the work that they have already done. At the moment I
don't think that it contains quite enough information. For example, I
think its important to store the start revision as well as the end
revision. Currently, the information that I consider important is this:
uuid1, path1@rev, startrevnum
uuid2, path2@rev, endrevnum
This information would be included in a property in the local working
directory to be commited with the rest of the changes. The property is
attached to the target of the merge (wether it be a directory or file).
uuid identifies the repository independant of the access method.
Storing the URL would not do.
path@rev is the path (e.g. /trunk, /branches/branch, etc...) in the
repository to the directory or file of the two sources. The @rev is
necessary in case the file or directory moves later on. By the way, I'm
playing in the code right now. Could someone tell me how I can parse a
URL into path_to_repository, path_inside_repository?
startrev and endrev are just what you think.
Since this information doesn't line up exactly with the svk merge ticket
I thought it would be best to come up with a new property name that
won't conflict with svk. A possible win here is that this property will
contain a superset of the svk merge ticket. So, in theory, svk could
easily be modified to make use of it if it finds it.
I plan to do a follow up post with some more thoughts that I have soon.
I'm currently trying to gather my thoughts in the little bit of time
that I have.
Cheers,
Carl
On Tue, Mar 29, 2005 at 08:47:25AM +0200, Ph. Marek wrote:
> On Saturday 26 March 2005 07:45, Carl Baldwin wrote:
> > I read up on the various things that people pointed me to. Thank you
> > again for your input. It seems that people have a lot of different
> > ideas for tracking merges. This does, indeed, appear to be a big job.
> >
> > I would propose a place to start working on this problem.
> Thank you for volunteering!
>
> > ...
> I see that you already know about svk, and so I beg you to use (if that's at
> all possible) to use the same property name and value, to achive
> interoperability.
>
> But if the goals (or means) are too different, you might need another
> property.
>
>
> Regards,
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Saturday 26 March 2005 07:45, Carl Baldwin wrote:
> I read up on the various things that people pointed me to. Thank you
> again for your input. It seems that people have a lot of different
> ideas for tracking merges. This does, indeed, appear to be a big job.
>
> I would propose a place to start working on this problem.
Thank you for volunteering!
> ...
I see that you already know about svk, and so I beg you to use (if that's at
all possible) to use the same property name and value, to achive
interoperability.
But if the goals (or means) are too different, you might need another
property.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Carl Baldwin <cn...@fc.hp.com>.
On Wed, Mar 30, 2005 at 09:59:17AM -0700, Carl Baldwin wrote:
> 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
^
|
Oops insert "solution" here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 30, 2005, at 10:59 AM, Carl Baldwin wrote:
>
> 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.
>
Great!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Carl Baldwin <cn...@fc.hp.com>.
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
Re: Merge tracking
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Erik Huelsmann" <e....@gmx.net> writes:
> > 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.
Well, to be clear, it was pushed back from 1.0 because 1.0 was defined
as "basically, replace CVS". But yes, your statements about
functionality and readiness for public consumptions are accurate. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Erik Huelsmann <e....@gmx.net>.
> 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
Re: Merge tracking
Posted by Helge Jensen <he...@slog.dk>.
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
Re: Merge tracking
Posted by Branko Čibej <br...@xbc.nu>.
Helge Jensen wrote:
> Ben Collins-Sussman wrote:
>
>>
>
>> I think you're already jumping the gun in trying to propose specific
>> types of merge-tracking properties. There's a much larger discussion
>> to be had first: what *is* merge-tracking? There seems to be a
>> whole class of problems by that name. We need to enumerate them,
>> prioritize them, etc.
>
>
> I think what Carl proposes is an excellent *small*-step towards
> merge-tracking: Simply recording the operations that have been done in
> a standardized form.
>
> * recording is importent for understanding how the content came to
> look as it does in revN -- This is done in comments right now, or
> properties in svk.
>
> * standardized is importent for sharing the representation between
> tools
>
> Is the choice really between "the grand solution" and "nothing"?
No, the choice is beteween "right solution" and "nothing".
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).
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.
> 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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Helge Jensen <he...@slog.dk>.
Ben Collins-Sussman wrote:
>
> I think you're already jumping the gun in trying to propose specific
> types of merge-tracking properties. There's a much larger discussion to
> be had first: what *is* merge-tracking? There seems to be a whole
> class of problems by that name. We need to enumerate them, prioritize
> them, etc.
I think what Carl proposes is an excellent *small*-step towards
merge-tracking: Simply recording the operations that have been done in a
standardized form.
* recording is importent for understanding how the content came to
look as it does in revN -- This is done in comments right now, or
properties in svk.
* standardized is importent for sharing the representation between tools
Is the choice really between "the grand solution" and "nothing"?
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.
--
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
Re: Merge tracking
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 26, 2005, at 12:45 AM, Carl Baldwin wrote:
>
> I am willing to put some time/effort toward this little piece. Before
> diving into it I would like to discuss with those who are interested
> exactly how this information will be recorded by the 'svn merge'
> command.
>
Hi Carl,
Glad you're interested in this task. You've not seen many responses
because most of us are busy trying to get a 1.2 release stable and out
the door. We've just spent months working on another 'huge' feature
(locking), and most of us don't have time/energy to start a bunch of
long design discussions for merge-tracking.
This discussion *will* happen... it's on our roadmap. I think you just
happened to choose a bad moment to try and attract attention.
Once svn 1.2 is out, the next thing we'd like to design is 'true
moves', because some of us feel that it's a prerequisite for
good-quality merge tracking.
Here's our rough roadmap:
http://subversion.tigris.org/roadmap.html
And here are some preliminary thoughts on merge tracking:
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
I think you're already jumping the gun in trying to propose specific
types of merge-tracking properties. There's a much larger discussion
to be had first: what *is* merge-tracking? There seems to be a whole
class of problems by that name. We need to enumerate them, prioritize
them, etc.
Again, you're welcome to plow forward. But you might get more
attention if you wait a month. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Carl Baldwin <cn...@fc.hp.com>.
I read up on the various things that people pointed me to. Thank you
again for your input. It seems that people have a lot of different
ideas for tracking merges. This does, indeed, appear to be a big job.
I would propose a place to start working on this problem. That is to
modify the 'svn merge' command to record the merge that it performs in a
'property' in the local sand-box. When the conflicts resulting from the
merge have been resolved then this little piece of information will be
committed to the repository. This will play nice with dump/load and
will not require any changes to the repository back-end.
Once this information is getting recorded in the repository then various
developers can go off in many different directions exploring the
different ways to use this information to make subversion 'smarter'.
This includes a 'smart merge' that knows what has been merged already
and can simply do the right thing when given a branch to merge into a
working copy.
I am willing to put some time/effort toward this little piece. Before
diving into it I would like to discuss with those who are interested
exactly how this information will be recorded by the 'svn merge'
command.
All of the information that we need to record is in the arguments passed
to svn merge. Basically, we need a simple format to encode the
arguments (URLs, starting/ending revs) so that other tools can be
written to use it.
What do we call the property? svn:merges?
Please let me know your thoughts and I will be glad to help.
Carl Baldwin
PS The svk 'merge ticket' records most of the information that I think
is important. I do believe that it discards one minor, but still
possibly important piece. It only records one revision and assumes that
any previous merge merged all changes up to the recorded revision. This
assumption might be OK, I just want to explore the possible
ramifications.
On Tue, Mar 15, 2005 at 04:31:30PM -0600, Josh Siegel wrote:
>
> >
> >Could someone point me some things on this topic? Maybe some specific
> >threads on the email list or a page on the subversion.tigris.org or
> >something?
> >
> >Thank you,
> >Carl
> >
> >
> >
> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
>
> this is a good place to start
>
> -josh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Josh Siegel <jo...@stormbirds.org>.
>
>Could someone point me some things on this topic? Maybe some specific
>threads on the email list or a page on the subversion.tigris.org or
>something?
>
>Thank you,
>Carl
>
>
>
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
this is a good place to start
-josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge tracking
Posted by Marcus Rueckert <da...@web.de>.
On 2005-03-15 14:57:30 -0700, Carl Baldwin wrote:
> Could someone point me some things on this topic? Maybe some specific
> threads on the email list or a page on the subversion.tigris.org or
> something?
> For additional commands, e-mail: dev-help@subversion.tigris.org
http://svn.haxx.se and search for "dev@subversion merge track"
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
hope this helps
darix
--
irssi - the client of the smart and beautiful people
http://www.irssi.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org