You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/12/05 03:45:31 UTC
About the whole-branch-merge branch
I promise that explaining today's work will be the first thing I do
after getting to work tomorrow (9AM Pacific)...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 05 Dec 2007, Mark Phippard wrote:
...
> > > But, I thought in the second case (coming back to trunk) we would be
> > > converting this into a 2-URL merge internally? I thought this was
> > > essentially just syntactic sugar? My point is that the properly
> > > crafted 2-URL merge would work fine in the situation I outlined, so as
> > > long as we can programmatically determine the right options, we could
> > > do the same. I thought that is basically what your proposal was also
> > > saying? I just want to relax (slightly) the WC revision requirement
> > > so that it is a little easier for someone to take advantage of this.
...
> Your original spec said you would take the REV
> of the WC and then make go to the URL, get is mergeinfo and make sure
> it had been synched up to that revision. It seems like you could
> easily turn this around. Go to the mergeinfo, find out what revision
> it had been synched to, and then just make sure the WC was at least at
> that revision.
I've added a very basic implementation of that (which probably doesn't
handle renames).
> I wonder once you go through this cycle once:
>
> 1) Create feature branch
> 2) Changes on feature branch
> 3) Synch with trunk
> 4) More change on feature branch
> 5) Synch with trunk
> 6) Merge back to trunk
>
> Now, suppose you want to make more changes on feature branch. Can the
> cycle just repeat? Does the user need to know that they should
> probably delete branch + recreate it?
Can't the feature branch can be reused without deletion?
Re: About the whole-branch-merge branch
Posted by Folker Schamel <sc...@spinor.com>.
Hi Mark!
> On Dec 6, 2007 9:55 AM, Folker Schamel <sc...@spinor.com> wrote:
>
>>> On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
>>>
>>>> Basically all the time you try to work around the fundamental problem
>>>> that your current mergeinfo scheme has not enough information
>>>> about the merge history.
>>> Folker, I have been thinking a lot about these comments (you've made
>>> them a dozen times now).
>> Yes; sorry if my comments have been annoying.
>>
>> (Due to lack of response, my assumption was that people
>> didn't understand my comments, so I tried to make them more clear
>> and apply them to particular issues people are working on.)
>
> I think the comments have been walking a fine line between helpful and
> noise. I think you have some good points, but you are also being
> fairly dismissive of the current approach and not very constructive in
> reaching a solution. We are not going to scrap everything because of
> a drive-by proposal.
>
>>> Anyway, Folker, perhaps you should look more closely at some of what
>>> Kamesh has been proposing. I suspect it is a lot closer to your
>>> proposal that you realize.
>> Yes, maybe. Honestly, I don't understand what Kamesh is working on.
>> However, the point is:
>>
>> As long as the meaning of mergeinfo does not change,
>> I think I should not have to care about Kamesh's work,
>> because i think mergeinfo should contain *all* information,
>> and SQLite tables should be only an optimization detail
>> containing only *redundant* information of mergeinfo.
>> Don't you agree?
>
> This is an example of what I am referring to. It really is not helpful.
>
> To answer your question ... no I do not really agree. I think of it
> more as the "repository" should contain the information and be able to
> answer queries. And yes the SQLite tables are an optimization the
> repository can use.
>
>> Do I understand you correctly that my assumption is wrong,
>> and that Kamesh's new SQLite table contains "extra information"
>> which *cannot* be reconstructed from the mergeinfo property?
>> What about svnadmin load then?
>
> Dump/Load will always be a "set in concrete" requirement that it has
> to work. When you load a repository the transactions are replayed and
> the information would be reconstructed as part of that process. Any
> solution would absolutely have to work and support this.
>
>> What about users or 3rd-party-tools who want to inspect that
>> "extra information" using an svn client?
>
> I do not think there should be any guarantee that these clients ought
> to be able to inspect a property and just use its contents. There
> should be formal API that gives answers to the questions that clients
> want to ask.
Of course, this is a valid design approach, but - if I am not totally
wrong - this is different from the (originally) planned design,
where SQLite contained just redundant information.
And if you are right and that design has changed,
then I am wondering why such a (fundamental) design aspect
may change silently.
And if I understand Kamesh's latest email correctly, even you
developers seem to have a different understanding of it.
(You and Kamesh's last email gives me even more the impression
that you developers don't have a clear common understanding
and vision of the issue, but of course I may be wrong.)
>
>> Regarding 1.5, I am sure that mergeinfo should be defined
>> in the right way before 1.5.
>> Then any feature or any hyper-smart merge algorithm
>> (based on that mergeinfo) can be delayed into future versions
>> as needed without having compatibility problems.
>
> I think we have, or can have, all the information that we need using
> the current fundamental design (branches included). It is entirely
> possible we are storing more information than it turns out we need.
> Recent optimizations have been removing that and we can continue to do
> so. You and Kamesh seem to have arrived at the same conclusion that
> there was a bit of information we were not accurately recording.
> Kamesh's branch is seeking to rectify that.
>
> I just want to be sure that people are listening to your suggestions.
> That being said, if you want them to do that you need to invest a
> little more effort, and respect, into understanding the work that is
> going on and try to incorporate your suggestions into that work.
> Telling us we have it all wrong and we need to start over just isn't
> going to get anywhere and your insights are going to be lost. No one
> is going to benefit if that happens.
I understand your point, but I think it is not completely fair.
My first main point is that I wanted to point to problems
with the mergeinfo scheme.
I think it *is* constructive to point to a problem,
even if I haven't an solution which is acceptable for you.
As soon as someone of you developers had said one sentence
"Yes, we are aware of that problem", then I would have been
quiet immediately, even if I don't understand your approach at all.
However, this did not happen, and so my impression was that
I didn't explain it well enough, so I tried to explain it better.
Furthermore, maybe as non-developer I have no right to do that at all,
and usually I am very reluctant to give tips from outside without
really helping in the dirty implementation work.
But in this case I was quite sure that I have a valid point.
The second aspect is that I made suggestions of how solving it,
exactly because I wanted to not stop at describing the problem.
I wanted to point out that there exist solutions.
Of course you have the right to reject my proposal because
it is too far away from your current approach.
But at least I *tried* to be constructive.
And honestly, I am still not sure if the problem can be solved
at all by just minor changes of your current approach.
So my impression is that you expect something from me
which I myself just don't see yet how this is possible at all.
I hope I am wrong...
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 6, 2007 9:55 AM, Folker Schamel <sc...@spinor.com> wrote:
> > On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
> >
> >> Basically all the time you try to work around the fundamental problem
> >> that your current mergeinfo scheme has not enough information
> >> about the merge history.
> >
> > Folker, I have been thinking a lot about these comments (you've made
> > them a dozen times now).
>
> Yes; sorry if my comments have been annoying.
>
> (Due to lack of response, my assumption was that people
> didn't understand my comments, so I tried to make them more clear
> and apply them to particular issues people are working on.)
I think the comments have been walking a fine line between helpful and
noise. I think you have some good points, but you are also being
fairly dismissive of the current approach and not very constructive in
reaching a solution. We are not going to scrap everything because of
a drive-by proposal.
> > Anyway, Folker, perhaps you should look more closely at some of what
> > Kamesh has been proposing. I suspect it is a lot closer to your
> > proposal that you realize.
>
> Yes, maybe. Honestly, I don't understand what Kamesh is working on.
> However, the point is:
>
> As long as the meaning of mergeinfo does not change,
> I think I should not have to care about Kamesh's work,
> because i think mergeinfo should contain *all* information,
> and SQLite tables should be only an optimization detail
> containing only *redundant* information of mergeinfo.
> Don't you agree?
This is an example of what I am referring to. It really is not helpful.
To answer your question ... no I do not really agree. I think of it
more as the "repository" should contain the information and be able to
answer queries. And yes the SQLite tables are an optimization the
repository can use.
> Do I understand you correctly that my assumption is wrong,
> and that Kamesh's new SQLite table contains "extra information"
> which *cannot* be reconstructed from the mergeinfo property?
> What about svnadmin load then?
Dump/Load will always be a "set in concrete" requirement that it has
to work. When you load a repository the transactions are replayed and
the information would be reconstructed as part of that process. Any
solution would absolutely have to work and support this.
> What about users or 3rd-party-tools who want to inspect that
> "extra information" using an svn client?
I do not think there should be any guarantee that these clients ought
to be able to inspect a property and just use its contents. There
should be formal API that gives answers to the questions that clients
want to ask.
> Regarding 1.5, I am sure that mergeinfo should be defined
> in the right way before 1.5.
> Then any feature or any hyper-smart merge algorithm
> (based on that mergeinfo) can be delayed into future versions
> as needed without having compatibility problems.
I think we have, or can have, all the information that we need using
the current fundamental design (branches included). It is entirely
possible we are storing more information than it turns out we need.
Recent optimizations have been removing that and we can continue to do
so. You and Kamesh seem to have arrived at the same conclusion that
there was a bit of information we were not accurately recording.
Kamesh's branch is seeking to rectify that.
I just want to be sure that people are listening to your suggestions.
That being said, if you want them to do that you need to invest a
little more effort, and respect, into understanding the work that is
going on and try to incorporate your suggestions into that work.
Telling us we have it all wrong and we need to start over just isn't
going to get anywhere and your insights are going to be lost. No one
is going to benefit if that happens.
I think Kamesh is capturing the information you think we need to. So
confirm that is true, and help him refine the algorithm we need to use
that information. I have also asked him to take a closer look at what
you have already posted.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Folker Schamel <sc...@spinor.com>.
Hi Daniel!
> On Thu, 06 Dec 2007, Kamesh Jayachandran wrote:
>> Folker Schamel wrote:
>>>> On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
>>>>
>>>>> Basically all the time you try to work around the fundamental problem
>>>>> that your current mergeinfo scheme has not enough information
>>>>> about the merge history.
>
> It's not that our mergeinfo doesn't contain enough information; rather,
> it's that the information isn't broken out into a format that is
> supportive of fast queries needed for cyclic cherry-picking merges.
By "mergeinfo" I mean the data in the mergeinfo property only,
which alone definitely contains not enough information.
>
>>>> Folker, I have been thinking a lot about these comments (you've made
>>>> them a dozen times now).
>>> Yes; sorry if my comments have been annoying.
>
> Yeah, it has been getting a bit tedious. That said, you have demonstated that
> you have a good handle on the issues involved in Merge Tracking.
>
> It'd be quite helpful if you'd take the time to understand the work that
> Mike Pilato just merged to the trunk, the whole-branch-merge branch that
> Dave, Karl and I have been working on this week, and the issue-2897 branch
> that Kamesh is working on. Some good discussion around how to meet the
> needs of the various use cases you've brought up with those branches would
> be great! Mike, for instance, seems to have followed the spirit of some of
> your suggestions for calculating merginfo for 2-URL merges.
>
>>> (Due to lack of response, my assumption was that people
>>> didn't understand my comments, so I tried to make them more clear
>>> and apply them to particular issues people are working on.)
>
> Or maybe we've been busy writing code, and reviewing each other's changes?
>
> ...
>>>> My understanding of your proposal in regards to mergeinfo is that we
>>>> should only record the explicit revisions that are merged by a given
>>>> merge. We can follow the history within the repository to get any
>>>> additional information we need.
>>> Exactly.
>
> Wouldn't this make transitive mergeinfo -- that is, mergeinfo introduced by
> merges of merges -- much more difficult and expensive to determine?
There are two separated aspects:
a) What information must be stored for solving merge-tracking problems
(or at least to be future-safe for solving these problems)?
The answer to this question should be very clear and simple.
And I strongly advocate exposing that information via the svnmerge property.
b) How should this information stored internally so that the required
access to this information is not expensive?
This may get arbitrary complex, for example using various
SQLite indices containing redundant data.
Your point adresses b), while I am addressing a).
> ...
>>>> 3) The extra mergeinfo is harmful because it makes it impossible to
>>>> look at the mergeinfo and understand the explicit revisions that were
>>>> merged in a given change.
>>>>
>>>> You seem to believe this is option 3.
>>> Exactly.
>>>
>>>> I suspect you are right, but
>>>> that we can "easily" turn this into one of the other two options. The
>>>> branch that Kamesh is working on for issue-2897 essentially does this
>>>> (if I understand his proposal correctly). What his branch does is add
>>>> an extra SQLite table that records the explicit revisions that were
>>>> merged for a given commit. He has then been working on the algorithms
>>>> to use this extra information to properly drive the reflective merges.
>>>>
>>>> It seems like there has been a movement to defer Kamesh's work until
>>>> after 1.5. Perhaps we should ask Kamesh to create a new branch where
>>>> he makes his scheme change and puts the code in place to populate the
>>>> table properly. We can deal with using this information in other
>>>> branches. I suspect the change he made could co-exist and be
>>>> coordinated with the other SQLite optimizations that David Glasser has
>>>> made. I would also think that this extra information that Kamesh has
>>>> been recording does not have the same deep copy/move problem that
>>>> David Glasser has found with our other info. I do not see why this
>>>> information needs to be copied. The point is to record for a given
>>>> commit (revision) what revisions were explicitly merged and from what
>>>> paths. That seems like a point in time entry that never needs to
>>>> change or propogate.
> ...
>>> As long as the meaning of mergeinfo does not change,
>>> I think I should not have to care about Kamesh's work,
>>> because i think mergeinfo should contain *all* information,
>>> and SQLite tables should be only an optimization detail
>>> containing only *redundant* information of mergeinfo.
>>> Don't you agree?
>>>
>>> Do I understand you correctly that my assumption is wrong,
>>> and that Kamesh's new SQLite table contains "extra information"
>>> which *cannot* be reconstructed from the mergeinfo property?
>
> As Mark said, we can reconstruct this information (as required by 'svnadmin
> load', and other use cases); but, we want it in a more easily query-able
> form.
>
> ...
>> issue-2897 branch does not record any extra information it rather
>> records relevant information to make the lookup faster. It just records
>> the merged_ranges_for_this_commit, /source, /target, commit_rev to
>> mergeinfo_changed table.
>
> Trying to describe this at a higher level, we need to be able to quickly
> determine not only the mergeinfo for a path at a given revision, but also
> the changes in mergeinfo on a path -- with history tracing -- over a revision
> range.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 06 Dec 2007, Kamesh Jayachandran wrote:
> Folker Schamel wrote:
> >>On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
> >>
> >>>Basically all the time you try to work around the fundamental problem
> >>>that your current mergeinfo scheme has not enough information
> >>>about the merge history.
It's not that our mergeinfo doesn't contain enough information; rather,
it's that the information isn't broken out into a format that is
supportive of fast queries needed for cyclic cherry-picking merges.
> >>Folker, I have been thinking a lot about these comments (you've made
> >>them a dozen times now).
> >
> >Yes; sorry if my comments have been annoying.
Yeah, it has been getting a bit tedious. That said, you have demonstated that
you have a good handle on the issues involved in Merge Tracking.
It'd be quite helpful if you'd take the time to understand the work that
Mike Pilato just merged to the trunk, the whole-branch-merge branch that
Dave, Karl and I have been working on this week, and the issue-2897 branch
that Kamesh is working on. Some good discussion around how to meet the
needs of the various use cases you've brought up with those branches would
be great! Mike, for instance, seems to have followed the spirit of some of
your suggestions for calculating merginfo for 2-URL merges.
> >(Due to lack of response, my assumption was that people
> >didn't understand my comments, so I tried to make them more clear
> >and apply them to particular issues people are working on.)
Or maybe we've been busy writing code, and reviewing each other's changes?
...
> >>My understanding of your proposal in regards to mergeinfo is that we
> >>should only record the explicit revisions that are merged by a given
> >>merge. We can follow the history within the repository to get any
> >>additional information we need.
> >
> >Exactly.
Wouldn't this make transitive mergeinfo -- that is, mergeinfo introduced by
merges of merges -- much more difficult and expensive to determine?
...
> >>3) The extra mergeinfo is harmful because it makes it impossible to
> >>look at the mergeinfo and understand the explicit revisions that were
> >>merged in a given change.
> >>
> >>You seem to believe this is option 3.
> >
> >Exactly.
> >
> >> I suspect you are right, but
> >>that we can "easily" turn this into one of the other two options. The
> >>branch that Kamesh is working on for issue-2897 essentially does this
> >>(if I understand his proposal correctly). What his branch does is add
> >>an extra SQLite table that records the explicit revisions that were
> >>merged for a given commit. He has then been working on the algorithms
> >>to use this extra information to properly drive the reflective merges.
> >>
> >>It seems like there has been a movement to defer Kamesh's work until
> >>after 1.5. Perhaps we should ask Kamesh to create a new branch where
> >>he makes his scheme change and puts the code in place to populate the
> >>table properly. We can deal with using this information in other
> >>branches. I suspect the change he made could co-exist and be
> >>coordinated with the other SQLite optimizations that David Glasser has
> >>made. I would also think that this extra information that Kamesh has
> >>been recording does not have the same deep copy/move problem that
> >>David Glasser has found with our other info. I do not see why this
> >>information needs to be copied. The point is to record for a given
> >>commit (revision) what revisions were explicitly merged and from what
> >>paths. That seems like a point in time entry that never needs to
> >>change or propogate.
...
> >As long as the meaning of mergeinfo does not change,
> >I think I should not have to care about Kamesh's work,
> >because i think mergeinfo should contain *all* information,
> >and SQLite tables should be only an optimization detail
> >containing only *redundant* information of mergeinfo.
> >Don't you agree?
> >
> >Do I understand you correctly that my assumption is wrong,
> >and that Kamesh's new SQLite table contains "extra information"
> >which *cannot* be reconstructed from the mergeinfo property?
As Mark said, we can reconstruct this information (as required by 'svnadmin
load', and other use cases); but, we want it in a more easily query-able
form.
...
> issue-2897 branch does not record any extra information it rather
> records relevant information to make the lookup faster. It just records
> the merged_ranges_for_this_commit, /source, /target, commit_rev to
> mergeinfo_changed table.
Trying to describe this at a higher level, we need to be able to quickly
determine not only the mergeinfo for a path at a given revision, but also
the changes in mergeinfo on a path -- with history tracing -- over a revision
range.
Re: About the whole-branch-merge branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Folker Schamel wrote:
> Hi Mark!
>
>> On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
>>
>>> Basically all the time you try to work around the fundamental problem
>>> that your current mergeinfo scheme has not enough information
>>> about the merge history.
>>
>> Folker, I have been thinking a lot about these comments (you've made
>> them a dozen times now).
>
> Yes; sorry if my comments have been annoying.
>
> (Due to lack of response, my assumption was that people
> didn't understand my comments, so I tried to make them more clear
> and apply them to particular issues people are working on.)
>
> > I am not sure that our scheme is as
>> different from what you propose as you think it is. I get the
>> impression you are looking at what you see in the svn:mergeinfo
>> property and basing your comments entirely on that. The information
>> that we have stored in the repository is different (or at least
>> richer).
>>
>> My understanding of your proposal in regards to mergeinfo is that we
>> should only record the explicit revisions that are merged by a given
>> merge. We can follow the history within the repository to get any
>> additional information we need.
>
> Exactly.
>
> > So let me make a few comments.
>>
>> 1) I suspect you are already aware of this, but as of a week or two
>> ago we no longer create mergeinfo for any operation but merge. Using
>> copy to create a branch used to create mergeinfo but no longer does.
>>
>> 2) When you do a merge, we create explicit mergeinfo that describes
>> the revisions you merged, but we also will merge in other differences
>> in the mergeinfo property. I think this is the crux of your
>> objection. I believe in the original design this additional
>> information was viewed as a benefit as it act as a bit of a local
>> cache. I think we agree that the information on these other merges is
>> needed, it is just that you think that information should be obtained
>> when needed by following the merge graph.
>>
>> So basically it boils down to that we are recording more mergeinfo
>> than you think we should. This can result in three scenarios:
>>
>> 1) The extra mergeinfo is harmless and provides no benefit. If this
>> is the case, we can optimize it away in a future version.
>>
>> 2) The extra mergeinfo is harmless and provides some marginal extra
>> benefit. Perhaps one or two local operations can benefit by having
>> the information in the WC. It remains to be seen if this true. It
>> seems like we always need to return to the repository when dealing
>> with mergeinfo.
>>
>> 3) The extra mergeinfo is harmful because it makes it impossible to
>> look at the mergeinfo and understand the explicit revisions that were
>> merged in a given change.
>>
>> You seem to believe this is option 3.
>
> Exactly.
>
> > I suspect you are right, but
>> that we can "easily" turn this into one of the other two options. The
>> branch that Kamesh is working on for issue-2897 essentially does this
>> (if I understand his proposal correctly). What his branch does is add
>> an extra SQLite table that records the explicit revisions that were
>> merged for a given commit. He has then been working on the algorithms
>> to use this extra information to properly drive the reflective merges.
> >
>> It seems like there has been a movement to defer Kamesh's work until
>> after 1.5. Perhaps we should ask Kamesh to create a new branch where
>> he makes his scheme change and puts the code in place to populate the
>> table properly. We can deal with using this information in other
>> branches. I suspect the change he made could co-exist and be
>> coordinated with the other SQLite optimizations that David Glasser has
>> made. I would also think that this extra information that Kamesh has
>> been recording does not have the same deep copy/move problem that
>> David Glasser has found with our other info. I do not see why this
>> information needs to be copied. The point is to record for a given
>> commit (revision) what revisions were explicitly merged and from what
>> paths. That seems like a point in time entry that never needs to
>> change or propogate.
>>
>> Anyway, Folker, perhaps you should look more closely at some of what
>> Kamesh has been proposing. I suspect it is a lot closer to your
>> proposal that you realize.
>
> Yes, maybe. Honestly, I don't understand what Kamesh is working on.
> However, the point is:
>
> As long as the meaning of mergeinfo does not change,
> I think I should not have to care about Kamesh's work,
> because i think mergeinfo should contain *all* information,
> and SQLite tables should be only an optimization detail
> containing only *redundant* information of mergeinfo.
> Don't you agree?
>
> Do I understand you correctly that my assumption is wrong,
> and that Kamesh's new SQLite table contains "extra information"
> which *cannot* be reconstructed from the mergeinfo property?
> What about svnadmin load then?
> What about users or 3rd-party-tools who want to inspect that
> "extra information" using an svn client?
>
issue-2897 branch does not record any extra information it rather
records relevant information to make the lookup faster. It just records
the merged_ranges_for_this_commit, /source, /target, commit_rev to
mergeinfo_changed table.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Folker Schamel <sc...@spinor.com>.
Hi Mark!
> On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
>
>> Basically all the time you try to work around the fundamental problem
>> that your current mergeinfo scheme has not enough information
>> about the merge history.
>
> Folker, I have been thinking a lot about these comments (you've made
> them a dozen times now).
Yes; sorry if my comments have been annoying.
(Due to lack of response, my assumption was that people
didn't understand my comments, so I tried to make them more clear
and apply them to particular issues people are working on.)
> I am not sure that our scheme is as
> different from what you propose as you think it is. I get the
> impression you are looking at what you see in the svn:mergeinfo
> property and basing your comments entirely on that. The information
> that we have stored in the repository is different (or at least
> richer).
>
> My understanding of your proposal in regards to mergeinfo is that we
> should only record the explicit revisions that are merged by a given
> merge. We can follow the history within the repository to get any
> additional information we need.
Exactly.
> So let me make a few comments.
>
> 1) I suspect you are already aware of this, but as of a week or two
> ago we no longer create mergeinfo for any operation but merge. Using
> copy to create a branch used to create mergeinfo but no longer does.
>
> 2) When you do a merge, we create explicit mergeinfo that describes
> the revisions you merged, but we also will merge in other differences
> in the mergeinfo property. I think this is the crux of your
> objection. I believe in the original design this additional
> information was viewed as a benefit as it act as a bit of a local
> cache. I think we agree that the information on these other merges is
> needed, it is just that you think that information should be obtained
> when needed by following the merge graph.
>
> So basically it boils down to that we are recording more mergeinfo
> than you think we should. This can result in three scenarios:
>
> 1) The extra mergeinfo is harmless and provides no benefit. If this
> is the case, we can optimize it away in a future version.
>
> 2) The extra mergeinfo is harmless and provides some marginal extra
> benefit. Perhaps one or two local operations can benefit by having
> the information in the WC. It remains to be seen if this true. It
> seems like we always need to return to the repository when dealing
> with mergeinfo.
>
> 3) The extra mergeinfo is harmful because it makes it impossible to
> look at the mergeinfo and understand the explicit revisions that were
> merged in a given change.
>
> You seem to believe this is option 3.
Exactly.
> I suspect you are right, but
> that we can "easily" turn this into one of the other two options. The
> branch that Kamesh is working on for issue-2897 essentially does this
> (if I understand his proposal correctly). What his branch does is add
> an extra SQLite table that records the explicit revisions that were
> merged for a given commit. He has then been working on the algorithms
> to use this extra information to properly drive the reflective merges.
>
> It seems like there has been a movement to defer Kamesh's work until
> after 1.5. Perhaps we should ask Kamesh to create a new branch where
> he makes his scheme change and puts the code in place to populate the
> table properly. We can deal with using this information in other
> branches. I suspect the change he made could co-exist and be
> coordinated with the other SQLite optimizations that David Glasser has
> made. I would also think that this extra information that Kamesh has
> been recording does not have the same deep copy/move problem that
> David Glasser has found with our other info. I do not see why this
> information needs to be copied. The point is to record for a given
> commit (revision) what revisions were explicitly merged and from what
> paths. That seems like a point in time entry that never needs to
> change or propogate.
>
> Anyway, Folker, perhaps you should look more closely at some of what
> Kamesh has been proposing. I suspect it is a lot closer to your
> proposal that you realize.
Yes, maybe. Honestly, I don't understand what Kamesh is working on.
However, the point is:
As long as the meaning of mergeinfo does not change,
I think I should not have to care about Kamesh's work,
because i think mergeinfo should contain *all* information,
and SQLite tables should be only an optimization detail
containing only *redundant* information of mergeinfo.
Don't you agree?
Do I understand you correctly that my assumption is wrong,
and that Kamesh's new SQLite table contains "extra information"
which *cannot* be reconstructed from the mergeinfo property?
What about svnadmin load then?
What about users or 3rd-party-tools who want to inspect that
"extra information" using an svn client?
Regarding 1.5, I am sure that mergeinfo should be defined
in the right way before 1.5.
Then any feature or any hyper-smart merge algorithm
(based on that mergeinfo) can be delayed into future versions
as needed without having compatibility problems.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 6, 2007 4:27 AM, Folker Schamel <sc...@spinor.com> wrote:
> Basically all the time you try to work around the fundamental problem
> that your current mergeinfo scheme has not enough information
> about the merge history.
Folker, I have been thinking a lot about these comments (you've made
them a dozen times now). I am not sure that our scheme is as
different from what you propose as you think it is. I get the
impression you are looking at what you see in the svn:mergeinfo
property and basing your comments entirely on that. The information
that we have stored in the repository is different (or at least
richer).
My understanding of your proposal in regards to mergeinfo is that we
should only record the explicit revisions that are merged by a given
merge. We can follow the history within the repository to get any
additional information we need. So let me make a few comments.
1) I suspect you are already aware of this, but as of a week or two
ago we no longer create mergeinfo for any operation but merge. Using
copy to create a branch used to create mergeinfo but no longer does.
2) When you do a merge, we create explicit mergeinfo that describes
the revisions you merged, but we also will merge in other differences
in the mergeinfo property. I think this is the crux of your
objection. I believe in the original design this additional
information was viewed as a benefit as it act as a bit of a local
cache. I think we agree that the information on these other merges is
needed, it is just that you think that information should be obtained
when needed by following the merge graph.
So basically it boils down to that we are recording more mergeinfo
than you think we should. This can result in three scenarios:
1) The extra mergeinfo is harmless and provides no benefit. If this
is the case, we can optimize it away in a future version.
2) The extra mergeinfo is harmless and provides some marginal extra
benefit. Perhaps one or two local operations can benefit by having
the information in the WC. It remains to be seen if this true. It
seems like we always need to return to the repository when dealing
with mergeinfo.
3) The extra mergeinfo is harmful because it makes it impossible to
look at the mergeinfo and understand the explicit revisions that were
merged in a given change.
You seem to believe this is option 3. I suspect you are right, but
that we can "easily" turn this into one of the other two options. The
branch that Kamesh is working on for issue-2897 essentially does this
(if I understand his proposal correctly). What his branch does is add
an extra SQLite table that records the explicit revisions that were
merged for a given commit. He has then been working on the algorithms
to use this extra information to properly drive the reflective merges.
It seems like there has been a movement to defer Kamesh's work until
after 1.5. Perhaps we should ask Kamesh to create a new branch where
he makes his scheme change and puts the code in place to populate the
table properly. We can deal with using this information in other
branches. I suspect the change he made could co-exist and be
coordinated with the other SQLite optimizations that David Glasser has
made. I would also think that this extra information that Kamesh has
been recording does not have the same deep copy/move problem that
David Glasser has found with our other info. I do not see why this
information needs to be copied. The point is to record for a given
commit (revision) what revisions were explicitly merged and from what
paths. That seems like a point in time entry that never needs to
change or propogate.
Anyway, Folker, perhaps you should look more closely at some of what
Kamesh has been proposing. I suspect it is a lot closer to your
proposal that you realize.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Folker Schamel <sc...@spinor.com>.
Mark Phippard wrote:
> On Dec 5, 2007 7:55 PM, David Glasser <gl...@davidglasser.net> wrote:
>> On Dec 5, 2007 4:38 PM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Dec 5, 2007 6:13 PM, David Glasser <gl...@davidglasser.net> wrote:
>>>> On Dec 5, 2007 1:20 PM, Mark Phippard <ma...@gmail.com> wrote:
>>>>> Here is a typical work flow.
>>>>>
>>>>> I am working on my feature branch and periodically staying in synch
>>>>> with trunk by just running:
>>>>>
>>>>> svn merge
>>>>> svn ci
>>>>>
>>>>> I did not have to look at revisions, everything just worked itself
>>>>> out. Merge tracking at its best. At some point I feel I am ready to
>>>>> go back to trunk. I might do one last synch and then spend some doing
>>>>> testing again, or I might want to just go back to trunk and work out
>>>>> conflicts and do final tests in my trunk WC. In either case, I do not
>>>>> readily know the revision of trunk I last merged into the branch. You
>>>>> are saying that I have to now look at the merge history to determine
>>>>> this information, and then run:
>>>>>
>>>>> svn switch -r THE-REV url://trunk
>>>>> svn merge url://branch
>>>>>
>>>>> I think that I ought to be able to just:
>>>>>
>>>>> svn switch url://trunk
>>>>> svn merge url://branch
>>>> Here's the thing.
>>>>
>>>> With the Subversion architecture as it is (specifically, the fact that
>>>> we lack a tree diff3), I do not believe that you can make "merge trunk
>>>> to branch" and "merge back to trunk" be the same operation.
>>>>
>>>> This isn't a matter of UI, although that's not irrelevant. It's
>>>> fundamentally the case that bidirectional mass cherry-picking is a
>>>> very hard problem that to the best of my knowledge no open source
>>>> system gets right. For this sort of feature branch work, you really
>>>> need to invoke a different operation to come back.
>>>>
>>>> Confusing? Sure. But still beats the conflict insanity of
>>>> bidirectional cherry-picking.
>>> But, I thought in the second case (coming back to trunk) we would be
>>> converting this into a 2-URL merge internally? I thought this was
>>> essentially just syntactic sugar? My point is that the properly
>>> crafter 2-URL merge would work fine in the situation I outlined, so as
>>> long as we can programmatically determine the right options, we could
>>> do the same. I thought that is basically what your proposal was also
>>> saying? I just want to relax (slightly) the WC revision requirement
>>> so that it is a little easier for someone to take advantage of this.
>> Yes, it's being converted into a 2-URL merge, but the 2-URL merge is
>> calculated based on the rev of the wc.
>>
>> On the other hand, I have no problem with people taking things that
>> are currently errors (SVN_ERR_CLIENT_NOT_READY_TO_MERGE) and making
>> them be supported, as long as it's safe. I figure, start with
>> something conservative, relax restrictions later.
>
> Yeah, I kind of understood that (which is why I was surprised to get
> the pushback in IRC). Your original spec said you would take the REV
> of the WC and then make go to the URL, get is mergeinfo and make sure
> it had been synched up to that revision. It seems like you could
> easily turn this around. Go to the mergeinfo, find out what revision
> it had been synched to, and then just make sure the WC was at least at
> that revision.
>
> I wonder once you go through this cycle once:
>
> 1) Create feature branch
> 2) Changes on feature branch
> 3) Synch with trunk
> 4) More change on feature branch
> 5) Synch with trunk
> 6) Merge back to trunk
>
> Now, suppose you want to make more changes on feature branch. Can the
> cycle just repeat? Does the user need to know that they should
> probably delete branch + recreate it?
My impression is that you are on a dangerous path:
You think very much in special cases (and its implementation details),
without having a (simple and flexible) scheme for addressing
the whole problem.
Basically all the time you try to work around the fundamental problem
that your current mergeinfo scheme has not enough information
about the merge history.
What about the common case of having multiple feature branches
and merging also between feature branches?
What about Mark's question?
What about merging bug fixes from some release branch
into a feature branch and trunk, but not into another
feature branch, and then merging the feature branches to trunk?
And so on.
BTW, the algorithm quoted in
http://svn.haxx.se/dev/archive-2007-12/0139.shtml
handles
svn switch -r THE-REV url://trunk
svn merge url://branch
and
svn switch url://trunk
svn merge url://branch
and also Mark's cycle scenario well automatically,
*without* treating these situations as special case.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 5, 2007 7:55 PM, David Glasser <gl...@davidglasser.net> wrote:
>
> On Dec 5, 2007 4:38 PM, Mark Phippard <ma...@gmail.com> wrote:
> >
> > On Dec 5, 2007 6:13 PM, David Glasser <gl...@davidglasser.net> wrote:
> > > On Dec 5, 2007 1:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> > > > Here is a typical work flow.
> > > >
> > > > I am working on my feature branch and periodically staying in synch
> > > > with trunk by just running:
> > > >
> > > > svn merge
> > > > svn ci
> > > >
> > > > I did not have to look at revisions, everything just worked itself
> > > > out. Merge tracking at its best. At some point I feel I am ready to
> > > > go back to trunk. I might do one last synch and then spend some doing
> > > > testing again, or I might want to just go back to trunk and work out
> > > > conflicts and do final tests in my trunk WC. In either case, I do not
> > > > readily know the revision of trunk I last merged into the branch. You
> > > > are saying that I have to now look at the merge history to determine
> > > > this information, and then run:
> > > >
> > > > svn switch -r THE-REV url://trunk
> > > > svn merge url://branch
> > > >
> > > > I think that I ought to be able to just:
> > > >
> > > > svn switch url://trunk
> > > > svn merge url://branch
> > >
> > > Here's the thing.
> > >
> > > With the Subversion architecture as it is (specifically, the fact that
> > > we lack a tree diff3), I do not believe that you can make "merge trunk
> > > to branch" and "merge back to trunk" be the same operation.
> > >
> > > This isn't a matter of UI, although that's not irrelevant. It's
> > > fundamentally the case that bidirectional mass cherry-picking is a
> > > very hard problem that to the best of my knowledge no open source
> > > system gets right. For this sort of feature branch work, you really
> > > need to invoke a different operation to come back.
> > >
> > > Confusing? Sure. But still beats the conflict insanity of
> > > bidirectional cherry-picking.
> >
> > But, I thought in the second case (coming back to trunk) we would be
> > converting this into a 2-URL merge internally? I thought this was
> > essentially just syntactic sugar? My point is that the properly
> > crafter 2-URL merge would work fine in the situation I outlined, so as
> > long as we can programmatically determine the right options, we could
> > do the same. I thought that is basically what your proposal was also
> > saying? I just want to relax (slightly) the WC revision requirement
> > so that it is a little easier for someone to take advantage of this.
>
> Yes, it's being converted into a 2-URL merge, but the 2-URL merge is
> calculated based on the rev of the wc.
>
> On the other hand, I have no problem with people taking things that
> are currently errors (SVN_ERR_CLIENT_NOT_READY_TO_MERGE) and making
> them be supported, as long as it's safe. I figure, start with
> something conservative, relax restrictions later.
Yeah, I kind of understood that (which is why I was surprised to get
the pushback in IRC). Your original spec said you would take the REV
of the WC and then make go to the URL, get is mergeinfo and make sure
it had been synched up to that revision. It seems like you could
easily turn this around. Go to the mergeinfo, find out what revision
it had been synched to, and then just make sure the WC was at least at
that revision.
I wonder once you go through this cycle once:
1) Create feature branch
2) Changes on feature branch
3) Synch with trunk
4) More change on feature branch
5) Synch with trunk
6) Merge back to trunk
Now, suppose you want to make more changes on feature branch. Can the
cycle just repeat? Does the user need to know that they should
probably delete branch + recreate it?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 5, 2007 4:38 PM, Mark Phippard <ma...@gmail.com> wrote:
>
> On Dec 5, 2007 6:13 PM, David Glasser <gl...@davidglasser.net> wrote:
> > On Dec 5, 2007 1:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> > > Here is a typical work flow.
> > >
> > > I am working on my feature branch and periodically staying in synch
> > > with trunk by just running:
> > >
> > > svn merge
> > > svn ci
> > >
> > > I did not have to look at revisions, everything just worked itself
> > > out. Merge tracking at its best. At some point I feel I am ready to
> > > go back to trunk. I might do one last synch and then spend some doing
> > > testing again, or I might want to just go back to trunk and work out
> > > conflicts and do final tests in my trunk WC. In either case, I do not
> > > readily know the revision of trunk I last merged into the branch. You
> > > are saying that I have to now look at the merge history to determine
> > > this information, and then run:
> > >
> > > svn switch -r THE-REV url://trunk
> > > svn merge url://branch
> > >
> > > I think that I ought to be able to just:
> > >
> > > svn switch url://trunk
> > > svn merge url://branch
> >
> > Here's the thing.
> >
> > With the Subversion architecture as it is (specifically, the fact that
> > we lack a tree diff3), I do not believe that you can make "merge trunk
> > to branch" and "merge back to trunk" be the same operation.
> >
> > This isn't a matter of UI, although that's not irrelevant. It's
> > fundamentally the case that bidirectional mass cherry-picking is a
> > very hard problem that to the best of my knowledge no open source
> > system gets right. For this sort of feature branch work, you really
> > need to invoke a different operation to come back.
> >
> > Confusing? Sure. But still beats the conflict insanity of
> > bidirectional cherry-picking.
>
> But, I thought in the second case (coming back to trunk) we would be
> converting this into a 2-URL merge internally? I thought this was
> essentially just syntactic sugar? My point is that the properly
> crafter 2-URL merge would work fine in the situation I outlined, so as
> long as we can programmatically determine the right options, we could
> do the same. I thought that is basically what your proposal was also
> saying? I just want to relax (slightly) the WC revision requirement
> so that it is a little easier for someone to take advantage of this.
Yes, it's being converted into a 2-URL merge, but the 2-URL merge is
calculated based on the rev of the wc.
On the other hand, I have no problem with people taking things that
are currently errors (SVN_ERR_CLIENT_NOT_READY_TO_MERGE) and making
them be supported, as long as it's safe. I figure, start with
something conservative, relax restrictions later.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 5, 2007 6:13 PM, David Glasser <gl...@davidglasser.net> wrote:
> On Dec 5, 2007 1:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> > Here is a typical work flow.
> >
> > I am working on my feature branch and periodically staying in synch
> > with trunk by just running:
> >
> > svn merge
> > svn ci
> >
> > I did not have to look at revisions, everything just worked itself
> > out. Merge tracking at its best. At some point I feel I am ready to
> > go back to trunk. I might do one last synch and then spend some doing
> > testing again, or I might want to just go back to trunk and work out
> > conflicts and do final tests in my trunk WC. In either case, I do not
> > readily know the revision of trunk I last merged into the branch. You
> > are saying that I have to now look at the merge history to determine
> > this information, and then run:
> >
> > svn switch -r THE-REV url://trunk
> > svn merge url://branch
> >
> > I think that I ought to be able to just:
> >
> > svn switch url://trunk
> > svn merge url://branch
>
> Here's the thing.
>
> With the Subversion architecture as it is (specifically, the fact that
> we lack a tree diff3), I do not believe that you can make "merge trunk
> to branch" and "merge back to trunk" be the same operation.
>
> This isn't a matter of UI, although that's not irrelevant. It's
> fundamentally the case that bidirectional mass cherry-picking is a
> very hard problem that to the best of my knowledge no open source
> system gets right. For this sort of feature branch work, you really
> need to invoke a different operation to come back.
>
> Confusing? Sure. But still beats the conflict insanity of
> bidirectional cherry-picking.
But, I thought in the second case (coming back to trunk) we would be
converting this into a 2-URL merge internally? I thought this was
essentially just syntactic sugar? My point is that the properly
crafter 2-URL merge would work fine in the situation I outlined, so as
long as we can programmatically determine the right options, we could
do the same. I thought that is basically what your proposal was also
saying? I just want to relax (slightly) the WC revision requirement
so that it is a little easier for someone to take advantage of this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 5, 2007 1:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> Here is a typical work flow.
>
> I am working on my feature branch and periodically staying in synch
> with trunk by just running:
>
> svn merge
> svn ci
>
> I did not have to look at revisions, everything just worked itself
> out. Merge tracking at its best. At some point I feel I am ready to
> go back to trunk. I might do one last synch and then spend some doing
> testing again, or I might want to just go back to trunk and work out
> conflicts and do final tests in my trunk WC. In either case, I do not
> readily know the revision of trunk I last merged into the branch. You
> are saying that I have to now look at the merge history to determine
> this information, and then run:
>
> svn switch -r THE-REV url://trunk
> svn merge url://branch
>
> I think that I ought to be able to just:
>
> svn switch url://trunk
> svn merge url://branch
Here's the thing.
With the Subversion architecture as it is (specifically, the fact that
we lack a tree diff3), I do not believe that you can make "merge trunk
to branch" and "merge back to trunk" be the same operation.
This isn't a matter of UI, although that's not irrelevant. It's
fundamentally the case that bidirectional mass cherry-picking is a
very hard problem that to the best of my knowledge no open source
system gets right. For this sort of feature branch work, you really
need to invoke a different operation to come back.
Confusing? Sure. But still beats the conflict insanity of
bidirectional cherry-picking.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 5, 2007 2:06 PM, David Glasser <gl...@davidglasser.net> wrote:
> We decided to start by implementing an operation that works only in a
> special case (which is carefully checked) and throws an error
> otherwise; the idea is that we can then (before or after 1.5 release)
> generalize it by offering support for some of the things that start as
> error cases.
>
> The specific case we're starting by handling (and the bulk of this is
> done; we're just ironing out bugs) is:
>
> * The working copy you're merging into is a pristine, single-rev,
> unswitched checkout: ie, it's something you could get as a fresh
> checkout of some URL@REV
>
> * The branch you're merging from has (according to mergeinfo) all of
> the changes on that URL up to REV integrated (using cmpilato's
> merge source normalization / location segments)
>
> In that case, you can just type
>
> $ svn merge url://to/feature-branch
>
> and it will do the right thing. We will also make it add mergeinfo
> for this merge.
In general, I am OK with this approach. Dan and I went down this same
patch back in May/June. Back then I think we discarded it because the
underlying 2-URL merge that would be executed would not update
mergeinfo and at the time we didn't see that being done. As you point
out cmpilato has made this more possible now, and even has a branch
where it has been implemented (today).
http://svn.collab.net/repos/svn/branches/better-two-url-merges/
My concern is that these REV requirements in the WC are too tight.
1. Must have an unswitched and complete checkout. I am OK with this,
I imagine most people would be.
2. Must be a single revision. I am so-so on this. It is a good idea,
and not too hard, so I can live with it.
3. Must be the last revision that the branch was synched with. This
one I have a problem with.
This last option is just another form of manual merge tracking and
will make the UI/workflow suck. You have a proposed workflow using
two working copies where it doesn't sound too bad, but it does not
sound terribly realistic either. Let's remember sussman's 80%/20%
blog post.
Here is a typical work flow.
I am working on my feature branch and periodically staying in synch
with trunk by just running:
svn merge
svn ci
I did not have to look at revisions, everything just worked itself
out. Merge tracking at its best. At some point I feel I am ready to
go back to trunk. I might do one last synch and then spend some doing
testing again, or I might want to just go back to trunk and work out
conflicts and do final tests in my trunk WC. In either case, I do not
readily know the revision of trunk I last merged into the branch. You
are saying that I have to now look at the merge history to determine
this information, and then run:
svn switch -r THE-REV url://trunk
svn merge url://branch
I think that I ought to be able to just:
svn switch url://trunk
svn merge url://branch
The code is already going to determine the last revision from trunk
that was merged into branch and then run a 2-URL merge. The merge API
itself can handle the WC being at either revision. Why create this
artificial barrier that ruins the user experience and UI?
On IRC, it was said that you would not want to clobber changes. I do
not get this. It is a merge. At worst it would create some conflicts
that would have to be resolved. Those same conflicts would just be
produced at commit time (would be out of date) when I update to HEAD.
Figure out a way where the revision of the WC is not critical to this
process and I think we have a good solution here.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: About the whole-branch-merge branch
Posted by John Peacock <jo...@havurah-software.org>.
David Glasser wrote:
> * The working copy you're merging into is a pristine, single-rev,
> unswitched checkout: ie, it's something you could get as a fresh
> checkout of some URL@REV
>
> * The branch you're merging from has (according to mergeinfo) all of
> the changes on that URL up to REV integrated (using cmpilato's
> merge source normalization / location segments)
>
> In that case, you can just type
>
> $ svn merge url://to/feature-branch
>
> and it will do the right thing. We will also make it add mergeinfo
> for this merge.
dglasser++
This is excellent and, speaking personally, this would cover most of my
merging needs, since I tend to use the "Branch per Change-Request"
pattern[*].
However, this wouldn't help at all the other primary task (merging
features between multiple mainline branches, i.e. the "Codeline per
Release" pattern[*]. But if the feature branches are always committed
as a single lumped change, it is relatively easy to use -c ### to pull
them in as needed.
John
*) http://www.cmcrossroads.com/bradapp/acme/branching/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge tracking] Merging all outstanding changes between ancestrally
related branches
Posted by Folker Schamel <sc...@spinor.com>.
> ...via merging from a single source URL into a WC. This requires that
> your merge source URL and WC are ancestrally-related.
>
>
> Use cases
> =========
>
> Easily allow merging of all (ancestrally-related) outstanding changes
> from one line of development to another, while accurately recording a
> mergeinfo audit trail.
>
> By "easily", the default behavior (merge algorithm) must support the
> use case encountered most often by the user: "bring un-cherry-picked
> branch WC up to date with its mainline". At the same time, the
> ability to merge a cherry-picked branch back into a mainline WC must
> also be easily accessible, and require the barest minimum of
> parameters. This latter case is important for avoiding repeated
> conflict resolution on long-lived/heavily cherry-picked branches.
>
>
> Proposal
> ========
>
> * Subversion 1.5, unlike previous versions, will let you specify one URL
> and an optional WC, via:
>
> svn [options...] merge URL [WC]
>
> * If you specify no revision range, or specifiy -c/-r options, you get a
> "cherry-picking" (or "unlumped") style merge, which potentially performs
> multiple editor drives, but will merge all eligible changes regardless of
> the state of your WC with respect to the line of development that you're
> merging from.
>
> * If you specify the --reintegrate option (bikeshed painting contest open
> for business), you get a "lumped" style merge, which merges the differences
> between the youngest revision from the WC that has been merged into the URL,
> and any peg revision specified for the URL (otherwise HEAD).
>
>
> Relation with Mike Pilato's recent 2-URL merge changes
> ======================================================
>
> The --reintegrate portion of the above proposal is basically a special
> case of Mike's recent changes (r28315 on trunk, r28303 on the
> mo-betta-two-url-merges branch), which requires some additional code
> from the whole-branch-merge branch. In terms of modularization, the
> proposal is to retain the code from the whole-branch-merge's
> libsvn_client/merge.c's ensure_wc_reflects_repository_subtree() and
> svn_client_merge_whole_branch() functions (renaming the latter to
> reflect whatever we name what I'm thinking of as the --reintegrate
> option).
What I don't understand yet is:
What is the need for the --reintergrate option at all?
The point is:
In both cases (with and without --reintergrate), the intention
of the user is exactly the same:
"Please merge all missing changes from URL into my wc!"
If the URL is already up-to-date, then it is just an an implementation
detail that Subversion can use a "lumped" style merge.
What about Subversion detecting that case automatically
without extra option?
When having a perfect merge-tracking some day, then an "unlumped" style
merge and an "lumped" style merge must/should give exactly the same
result anyway.
It is "only" a limitation of the current merging implementation
that it cannot handle the general case yet, so that the current
implementation has to handle different special cases
differently to handle the standard use cases.
But I think that this should be an implementation detail,
which should be not exposed to the user.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge tracking] Merging all outstanding changes between ancestrally related branches
Posted by Karl Fogel <kf...@red-bean.com>.
"Daniel L. Rall" <dl...@finemaltcoding.com> writes:
> ...via merging from a single source URL into a WC. This requires that
> your merge source URL and WC are ancestrally-related.
So (being fast-and-loose with notation here) this is for the following
case, right?:
$ svn cp ^/trunk ^/branches/B
$ svn co ^/branches/B Bwc
$ cd Bwc
$ [... do work in Bwc, commit changes, develop the branch, etc ...]
$ svn merge ^/trunk
$ [... resolve conflicts, commit ...]
$ [... do more work in Bwc ...]
$ svn merge ^/trunk
$ [... resolve conflicts, commit ...]
$ [... do more work in Bwc ...]
$ svn merge ^/trunk
$ [... lather, rinse, repeat ...]
(Just making completely sure I'm on the same page as you.)
> Use cases
> =========
>
> Easily allow merging of all (ancestrally-related) outstanding changes
> from one line of development to another, while accurately recording a
> mergeinfo audit trail.
E.g. from trunk to branch, in the above example, although it would
work as well for a branch off another branch, etc.
> By "easily", the default behavior (merge algorithm) must support the
> use case encountered most often by the user: "bring un-cherry-picked
> branch WC up to date with its mainline". At the same time, the
> ability to merge a cherry-picked branch back into a mainline WC must
> also be easily accessible, and require the barest minimum of
> parameters. This latter case is important for avoiding repeated
> conflict resolution on long-lived/heavily cherry-picked branches.
*Very* well said! This language should get folded into the
merge-tracking req/design docs.
> Proposal
> ========
>
> * Subversion 1.5, unlike previous versions, will let you specify one URL
> and an optional WC, via:
>
> svn [options...] merge URL [WC]
>
> * If you specify no revision range, or specifiy -c/-r options, you get a
> "cherry-picking" (or "unlumped") style merge, which potentially performs
> multiple editor drives, but will merge all eligible changes regardless of
> the state of your WC with respect to the line of development that you're
> merging from.
Excellent (and again, well-expressed).
> * If you specify the --reintegrate option (bikeshed painting contest open
> for business), you get a "lumped" style merge, which merges the differences
> between the youngest revision from the WC that has been merged into the URL,
> and any peg revision specified for the URL (otherwise HEAD).
Okay, I was confused for a moment, but now I think I understand. This
option is for merging the branch into a *trunk* wc, right? So you'd
run:
$ cd up-to-date-trunk-wc
$ svn merge --reintegrate url_to_branch_B[@PEG]
Am I still with you?
This description doesn't say what happens with mergeinfo, but I guess
that's appropriate: you're talking about the user-level view of how
things work. The mergeinfo should do whatever is necessary to make
this behavior happen.
> Relation with Mike Pilato's recent 2-URL merge changes
> ======================================================
>
> The --reintegrate portion of the above proposal is basically a special
> case of Mike's recent changes (r28315 on trunk, r28303 on the
> mo-betta-two-url-merges branch), which requires some additional code
> from the whole-branch-merge branch. In terms of modularization, the
> proposal is to retain the code from the whole-branch-merge's
> libsvn_client/merge.c's ensure_wc_reflects_repository_subtree() and
> svn_client_merge_whole_branch() functions (renaming the latter to
> reflect whatever we name what I'm thinking of as the --reintegrate
> option).
This has to count, overall, as one of the most comprehensible mails on
a normally incomprehensible topic that we've ever seen on this list.
+1 to the proposal!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge tracking] Merging all outstanding changes between ancestrally related branches
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 7, 2007 4:15 PM, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
> ...via merging from a single source URL into a WC. This requires that
> your merge source URL and WC are ancestrally-related.
>
>
> Use cases
> =========
>
> Easily allow merging of all (ancestrally-related) outstanding changes
> from one line of development to another, while accurately recording a
> mergeinfo audit trail.
>
> By "easily", the default behavior (merge algorithm) must support the
> use case encountered most often by the user: "bring un-cherry-picked
> branch WC up to date with its mainline". At the same time, the
> ability to merge a cherry-picked branch back into a mainline WC must
> also be easily accessible, and require the barest minimum of
> parameters. This latter case is important for avoiding repeated
> conflict resolution on long-lived/heavily cherry-picked branches.
>
>
> Proposal
> ========
>
> * Subversion 1.5, unlike previous versions, will let you specify one URL
> and an optional WC, via:
>
> svn [options...] merge URL [WC]
>
> * If you specify no revision range, or specifiy -c/-r options, you get a
> "cherry-picking" (or "unlumped") style merge, which potentially performs
> multiple editor drives, but will merge all eligible changes regardless of
> the state of your WC with respect to the line of development that you're
> merging from.
>
> * If you specify the --reintegrate option (bikeshed painting contest open
> for business), you get a "lumped" style merge, which merges the differences
> between the youngest revision from the WC that has been merged into the URL,
> and any peg revision specified for the URL (otherwise HEAD).
I had a fairly long alternate proposal but then decided I like this
better and it makes the most sense. So +1 from me, including the
name.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[merge tracking] Merging all outstanding changes between ancestrally related branches
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
...via merging from a single source URL into a WC. This requires that
your merge source URL and WC are ancestrally-related.
Use cases
=========
Easily allow merging of all (ancestrally-related) outstanding changes
from one line of development to another, while accurately recording a
mergeinfo audit trail.
By "easily", the default behavior (merge algorithm) must support the
use case encountered most often by the user: "bring un-cherry-picked
branch WC up to date with its mainline". At the same time, the
ability to merge a cherry-picked branch back into a mainline WC must
also be easily accessible, and require the barest minimum of
parameters. This latter case is important for avoiding repeated
conflict resolution on long-lived/heavily cherry-picked branches.
Proposal
========
* Subversion 1.5, unlike previous versions, will let you specify one URL
and an optional WC, via:
svn [options...] merge URL [WC]
* If you specify no revision range, or specifiy -c/-r options, you get a
"cherry-picking" (or "unlumped") style merge, which potentially performs
multiple editor drives, but will merge all eligible changes regardless of
the state of your WC with respect to the line of development that you're
merging from.
* If you specify the --reintegrate option (bikeshed painting contest open
for business), you get a "lumped" style merge, which merges the differences
between the youngest revision from the WC that has been merged into the URL,
and any peg revision specified for the URL (otherwise HEAD).
Relation with Mike Pilato's recent 2-URL merge changes
======================================================
The --reintegrate portion of the above proposal is basically a special
case of Mike's recent changes (r28315 on trunk, r28303 on the
mo-betta-two-url-merges branch), which requires some additional code
from the whole-branch-merge branch. In terms of modularization, the
proposal is to retain the code from the whole-branch-merge's
libsvn_client/merge.c's ensure_wc_reflects_repository_subtree() and
svn_client_merge_whole_branch() functions (renaming the latter to
reflect whatever we name what I'm thinking of as the --reintegrate
option).
Re: About the whole-branch-merge branch
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 05 Dec 2007, David Glasser wrote:
...
> It seems that cmpilato is also working on a similar feature to this
> branch. I'm not exactly sure how it compares to what we're doing.
Mike merged his work into trunk today. We need to identify the differences
between the whole-branch-merge branch and Mike's work to decide on how to
proceed.
Re: About the whole-branch-merge branch
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 4, 2007 7:45 PM, David Glasser <gl...@davidglasser.net> wrote:
> I promise that explaining today's work will be the first thing I do
> after getting to work tomorrow (9AM Pacific)...
The main idea behind yesterday's work is this observation: the action
"merge everything from branch A to branch B" actually could mean two
entirely different things:
* Take all the changes that have been committed on branch A and make
the same changes on branch B, ignoring those that have already been
moved over. ie, "move the changes", or "pick all the unpicked
cherries (cherry-harvest?)"
* Take the contents of branch A, which already represents a
combination of all the work on branch A and branch B, and make
branch B have the same contents. This is what happens when you're
"done" with a feature branch, have already reconciled trunk changes
with it, and are ready to load the feature into trunk. In a
high-level sense it's really a rename or rebase operation: kind of
like "svn rm url://B; svn cp url://A url://B".
In fact, according to the svnbook, the preferred way to maintain a
feature branch (pre-1.5) is to use commands of the former kind to
cherry-pick changes from trunk to feature branch; once the feature is
done on the feature branch *and* the feature branch has all of the new
work from trunk merged to it using commands of the first kind, you
make a trunk checkout and use a two-URL merge to do a second-kind
merge into trunk, and commit that.
There are two annoyances with merging a feature branch back to trunk
this way in SVN today:
(1) The command you're supposed to type is essentially
$ svn merge url://to/trunk@1234 url://to/branch@1234 wc-of-trunk-1234
When this is the operation you're trying to do, the first URL really
is redundant with the wc. Having to type out both makes this sort of
operation more difficult for the user. (Note that before 1.5,
"svn merge URL [WC]" was meaningless.)
(2) It's important that the feature branch you're merging into your
trunk WC really does represent all of the trunk development in WC,
or else you will accidentally unmerge some of that development. We
could check this with mergeinfo, but at the moment we don't.
It's my belief that for "merge feature branch back to trunk", you
really *do* want to be doing a merge of the second kind, not of the
first kind. That is, if you have a feature branch and have kept it up
to date with trunk, and have already tested that your feature works,
you just want to directly put the exact tree you have tested onto
trunk, by taking one diff and applying that. You *don't* want to
"reverse cherry-pick": that is, you *don't* want to say "find all the
commits I did on my feature branch to create my feature, and apply
them one at a time to the current trunk". That is very unlikely to
work; what it is likely to do is make you resolve the same stupid
conflicts over and over for every single revision that is
cherry-picked back to trunk. (svk does this in its "unlumped" merge
modes; it is frustrating enough that I just gave up on using
"unlumped" merge. There is nothing that can make you hate your
version control system as much as sitting there making the same
one-line change to code you haven't touched in weeks over and over
again during one merge operation.)
So! The point of the whole-branch-merge branch is to add support for
"whole-branch merges" in a way that requires the user to track less
information. That is, we're taking a previously-recommended merge
operation and letting Subversion fill in some of the parameters for
you, which is really what 1.5 Merge Tracking is all about.
This will support "merge feature branch back to trunk" in a different
way from #2897. We essentially are redefining #2897 to specifically
be about bidirectional *cherry-picking*, and considering that to be a
1.6 feature. (Some analysis of other systems, such as git and
mercurial, make me believe that they do not handle bidirectional
cherrypicking in an effective manner either.)
We decided to start by implementing an operation that works only in a
special case (which is carefully checked) and throws an error
otherwise; the idea is that we can then (before or after 1.5 release)
generalize it by offering support for some of the things that start as
error cases.
The specific case we're starting by handling (and the bulk of this is
done; we're just ironing out bugs) is:
* The working copy you're merging into is a pristine, single-rev,
unswitched checkout: ie, it's something you could get as a fresh
checkout of some URL@REV
* The branch you're merging from has (according to mergeinfo) all of
the changes on that URL up to REV integrated (using cmpilato's
merge source normalization / location segments)
In that case, you can just type
$ svn merge url://to/feature-branch
and it will do the right thing. We will also make it add mergeinfo
for this merge.
If this works, I think we can happily defer #2897 to 1.6.
Note that so far, nothing for this feature requires sqlite. Our
branch is based on my branch which adds extra metadata to FSFS
noderevs to allow for efficient mergeinfo queries of the kind
currently made.
(As far as sqlite goes, if we do decide to merge this feature branch
to trunk, I would like us to at least temporarily stop using sqlite
for mergeinfo queries, though we can leave the indexing code there for
a little bit if we want. This will cause some tests to fail: these
tests rely on mergeinfo queries on nonexistent paths to not throw an
error, which I think is incorrect. Even if we end up later
reintegrating sqlite because we later need to make more sophisticated
queries, we should fix the bugs that are causing us to send queries on
nonexistent paths!)
It seems that cmpilato is also working on a similar feature to this
branch. I'm not exactly sure how it compares to what we're doing.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org