You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/08/12 17:38:51 UTC
Re: svn commit: rev 6715 - in branches/neon-0.24
sergeyli@tigris.org writes:
> Log:
> Merge back from trunk, r 6615:6714 incl.
Sergey, can you describe your plan here? I think "rebranch" means
something different to you than it does to me :-).
You just merged a bunch of changes into trunk. The procedure for
rebranching is:
1. Delete the current Neon-0.24 branch, since all (or 90%) of those
changes are in trunk now.
2. Create a new Neon-0.24 branch, based on the post-merge trunk.
3. Port any remaining changes from your old Neon-0.24 branch to the
new one ("remaining" means ones that were not merged into trunk).
There's no point merging changes from branch into trunk, and then
immediately back into the branch again :-)... That doesn't get you
anything.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net writes:
> If you've already made changes in the branch since you merged the
> changes from trunk, that's okay, you can port them over again after
> recreating the branch. Changes in your working copy can of course be
> saved with 'svn diff'.
Or, 'svn switch new_branch_URL' will move your working copy to the new
branch, and still preserve local mods.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
Jack Repenning wrote:
> At 3:22 PM -0400 8/19/03, Sergey A. Lipnevich wrote:
>
>> Let's say I create a branch by rev r16, then commit two revisions on
>> branch, r17 and r18, and merge r17 into trunk by revision r32, and
>> then "rebranch:" delete the branch (r33) and copy the trunk over
>> (r34). The change r18 is left out in the "old" branch. Now, I go to a
>> branch root and do a merge of r16:32, because I do not want to dig
>> out what exactly changes have been left out after merging with trunk
>> and rebranching. This merge is going to give me r17 changes back, now
>> on the new branch, that's for sure. But, is this merge going to
>> create any conflicts, and if yes, why? Is r17 going to introduce a
>> conflict "with itself?"
>
>
> No. The algorithm is text-based, and the text is identical, so the
> merge doesn't have any trouble.
Right.
> Now, if you want to clutter up your example with some
> not-quite-identical text (which is easy enough to do in real life), I
> might give a different answer! But it would be the answer you expect,
> now that I've said "text-based."
I agree, that'd happen if context of r17 changed on the trunk. I have
trouble understanding though how would such a merge differ from an
initial merge from branch to trunk, but that's just me. I'll figure this
out by trial and error I think :-).
Thanks!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by Jack Repenning <jr...@collab.net>.
At 3:22 PM -0400 8/19/03, Sergey A. Lipnevich wrote:
>Let's say I create a branch by rev r16, then commit two revisions on
>branch, r17 and r18, and merge r17 into trunk by revision r32, and
>then "rebranch:" delete the branch (r33) and copy the trunk over
>(r34). The change r18 is left out in the "old" branch. Now, I go to
>a branch root and do a merge of r16:32, because I do not want to dig
>out what exactly changes have been left out after merging with trunk
>and rebranching. This merge is going to give me r17 changes back,
>now on the new branch, that's for sure. But, is this merge going to
>create any conflicts, and if yes, why? Is r17 going to introduce a
>conflict "with itself?"
No. The algorithm is text-based, and the text is identical, so the
merge doesn't have any trouble.
Now, if you want to clutter up your example with some
not-quite-identical text (which is easy enough to do in real life), I
might give a different answer! But it would be the answer you
expect, now that I've said "text-based."
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
cmpilato@collab.net wrote:
>"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
>
>
>
>>"less rules, more tools"
>>
>>
>
>Not bad. But try "fewer rules, more tools". :-)
>
>
One hit, on MSN :-(. I'd stick to mine ;-), my name does imply that I'm
not a native English speaker, so I'm entitled to such mistakes :-D.
Thanks!
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by cm...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> "less rules, more tools"
Not bad. But try "fewer rules, more tools". :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
kfogel@collab.net wrote:
>>Saving changes with `svn diff' is difficult to explain to a non-caring
>>colleague who just wants the version control system to be out of the
>>way, so I'd prefer the scenario I described above, if it works.
>>
>>
>
>It's fine to do it at home, just please not in Subversion's own tree
>:-). I'm mainly trying to have 'svn log -v' and 'svn diff' give
>accurate pictures of what has changed.
>
>
Sure, that's what I meant when I was asking these questions: I'm not
trying to change Subversion policy, of course not. I like the
disciplined way that the SVN team practices, very much so.
OTOH, I'm trying to establish good/reliable/easy/working patterns to
pass on to other people that I work with. I'm also a firm believer in
"less rules, more tools" ideology (I've just made this slogan up, sounds
kinda cool, no? no search engines turn this up, I must patent it quick
:-D ), where people don't have to read a gamut of docs to be productive,
instead they're offered to use tools that guide and help them do their
jobs. From this POV, Subversion is a huge step up from CVS, for example.
OK, off-topic talk :-). Thanks!
Sergey.
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> Yes it is, thanks! The question was slightly different, however. Let's
> say I create a branch by rev r16, then commit two revisions on branch,
> r17 and r18, and merge r17 into trunk by revision r32, and then
> "rebranch:" delete the branch (r33) and copy the trunk over (r34). The
> change r18 is left out in the "old" branch. Now, I go to a branch root
> and do a merge of r16:32, because I do not want to dig out what
> exactly changes have been left out after merging with trunk and
> rebranching. This merge is going to give me r17 changes back, now on
> the new branch, that's for sure. But, is this merge going to create
> any conflicts, and if yes, why? Is r17 going to introduce a conflict
> "with itself?"
I'm not sure how to answer this, except to say "Don't do things that
way." :-)
If you merge only part of a branch into trunk, and then delete the
branch, then yes, you have to keep track of what things you didn't
merge, so you can do them later.
Changes won't conflict with themselves, if neither they nor their
context changed in the destination. But why ask for trouble? I think
the simplest thing is to minimize the number of times the same change
must be ported from one line of development to another. Whenever you
can get a change via an implied copy, that's better.
Specifically, whenever you find yourself porting a change back to a
line that *already has the change*, you should be suspicious. (It
would be nice if Subversion did the bookkeeping for you, but it
doesn't.)
> Saving changes with `svn diff' is difficult to explain to a non-caring
> colleague who just wants the version control system to be out of the
> way, so I'd prefer the scenario I described above, if it works.
It's fine to do it at home, just please not in Subversion's own tree
:-). I'm mainly trying to have 'svn log -v' and 'svn diff' give
accurate pictures of what has changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
kfogel@collab.net wrote:
>Is it clear now why you should delete your branch and rebranch (i.e.,
>'svn cp') it from trunk, instead of merging many changes across from
>trunk to the branch?
>
Yes it is, thanks! The question was slightly different, however. Let's
say I create a branch by rev r16, then commit two revisions on branch,
r17 and r18, and merge r17 into trunk by revision r32, and then
"rebranch:" delete the branch (r33) and copy the trunk over (r34). The
change r18 is left out in the "old" branch. Now, I go to a branch root
and do a merge of r16:32, because I do not want to dig out what exactly
changes have been left out after merging with trunk and rebranching.
This merge is going to give me r17 changes back, now on the new branch,
that's for sure. But, is this merge going to create any conflicts, and
if yes, why? Is r17 going to introduce a conflict "with itself?"
>If you've already made changes in the branch since you merged the
>changes from trunk, that's okay, you can port them over again after
>recreating the branch. Changes in your working copy can of course be
>saved with 'svn diff'.
>
>
Saving changes with `svn diff' is difficult to explain to a non-caring
colleague who just wants the version control system to be out of the
way, so I'd prefer the scenario I described above, if it works.
Thanks for the explanations!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> I suppose if I'm doing the merge and the change is already there it
> should simply do nothing. For example, when I merged from trunk back
> into branch, I effectively merged my changes with mine same changes,
> and SVN didn't complain as it shouldn't have. Why would I have to
> /selectively/ do it if I can do it all at once? Or can I? Thanks!
It's not the same, it only *looks* the same, until you try to do the
second merge -- then you start to have problems. This is very
important, so I'll try to give a clearer and more complete explanation
than I did before.
Suppose we do it your way:
1. Copy Trunk to Branch
2. Commit various changes to Branch
[meanwhile, other people are committing changes to Trunk]
3. Merge some (but not all) of the Branch changes to Trunk, commit.
4. Now merge *all* Trunk changes since step 1 into Branch. This
includes, of course, the Branch changes that were ported to
Trunk in step 3.
5. Continue development on Branch.
6. Merge all "remaining" changes to Trunk, that is, all changes in
Branch not previously merged to Trunk.
The problem now is that all those changes committed to Branch in step
4 show up as actual *changes* in Branch. So if any of those areas of
the code also changed in Trunk between steps 4 and 6, then you'll get
conflicts when you merge.
But if step 4 had been "delete Branch, recopy it from Trunk", then
there would be no problem, because although the same Trunk content
would be present in Branch as in your method, the content would not
show up as *changes* in Branch's history. The actual commits on
Branch would be only changes that are semantically related to the
purpose of the Branch -- and later, the merge back to Trunk will not
get any unecessary conflicts.
Your way commits many "changes" to the branch, but only some of those
changes are related to the work you're doing on the branch. Thus the
history is confusing to follow, and diffs hard to choose.
While these two goals are separate...
- Don't put non-changes into history as changes
- Don't generate unnecessary conflicts
... in practice they go together.
Is it clear now why you should delete your branch and rebranch (i.e.,
'svn cp') it from trunk, instead of merging many changes across from
trunk to the branch?
If you've already made changes in the branch since you merged the
changes from trunk, that's okay, you can port them over again after
recreating the branch. Changes in your working copy can of course be
saved with 'svn diff'.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
kfogel@collab.net wrote:
>"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
>
>
>>Oh, /now/ I'm beginning to understand. So, when I delete the branch
>>and copy over the trunk, I have to merge into this same branch using
>>-r
>><revision that started the "old" branch>:<revision before creation of
>>the "new" branch>. I think this time I got it.
>>
>>
>
>Not quite. The choice of start and end revision will depend on what
>changes you're trying to port from the new branch to the old one. It
>should include only changes that were never ported to trunk, since
>those are therefore also not present in the new branch. Whether you
>want all of those changes, or just some, or what, will depend on their
>semantics. You may even need to do multiple merges, using different,
>disjoint revision ranges...
>
>Does it become clearer now?
>
>
I suppose if I'm doing the merge and the change is already there it
should simply do nothing. For example, when I merged from trunk back
into branch, I effectively merged my changes with mine same changes, and
SVN didn't complain as it shouldn't have. Why would I have to
/selectively/ do it if I can do it all at once? Or can I? Thanks!
Sergey.
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> Oh, /now/ I'm beginning to understand. So, when I delete the branch
> and copy over the trunk, I have to merge into this same branch using
> -r
> <revision that started the "old" branch>:<revision before creation of
> the "new" branch>. I think this time I got it.
Not quite. The choice of start and end revision will depend on what
changes you're trying to port from the new branch to the old one. It
should include only changes that were never ported to trunk, since
those are therefore also not present in the new branch. Whether you
want all of those changes, or just some, or what, will depend on their
semantics. You may even need to do multiple merges, using different,
disjoint revision ranges...
Does it become clearer now?
> Thanks for your
> patience! You and the entire Subversion team continue to amaze me, I
> think many OSS and proprietory projects would benefit if they use
> Subversion as a case study.
:-) No need to thank us -- we thank you for doing all this work!
But note that the branching techniques I'm describing here aren't
really Subversion-specific. I have used them (somewhat more
painfully) in CVS, and I'm pretty sure others have used them in other
systems.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
Oh, /now/ I'm beginning to understand. So, when I delete the branch and
copy over the trunk, I have to merge into this same branch using -r
<revision that started the "old" branch>:<revision before creation of
the "new" branch>. I think this time I got it. Thanks for your patience!
You and the entire Subversion team continue to amaze me, I think many
OSS and proprietory projects would benefit if they use Subversion as a
case study.
kfogel@collab.net wrote:
>"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
>
>
>>Yes it does, thanks! My only concern here is that in the middle of
>>rebranching I'd have to save and then reapply changes that didn't make
>>it to the trunk.
>>
>>
>
>You don't have to save them -- they're already saved in the
>repository, in the old version of your branch.
>
>
>
>>I guess the decision on the merge strategy has to be
>>made on a per-project basis. In a corporate setting, I'd be reluctant
>>to use Subversion's rebranching, out of fear of losing unmerged
>>changes (it's more difficult to explain this to team members to begin
>>with).
>>
>>
>
>The only kind of change you ever need to fear losing is an uncommitted
>one, and that's true no matter what kind of branching scheme you're
>using. Of the two branching schemes we're discussing, neither
>involves saving uncommitted changes in a working copy while some other
>operation is performed.
>
>-K
>
>
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> Yes it does, thanks! My only concern here is that in the middle of
> rebranching I'd have to save and then reapply changes that didn't make
> it to the trunk.
You don't have to save them -- they're already saved in the
repository, in the old version of your branch.
> I guess the decision on the merge strategy has to be
> made on a per-project basis. In a corporate setting, I'd be reluctant
> to use Subversion's rebranching, out of fear of losing unmerged
> changes (it's more difficult to explain this to team members to begin
> with).
The only kind of change you ever need to fear losing is an uncommitted
one, and that's true no matter what kind of branching scheme you're
using. Of the two branching schemes we're discussing, neither
involves saving uncommitted changes in a working copy while some other
operation is performed.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
kfogel@collab.net wrote:
>Look at it this way: why did you intially merge your changes into
>trunk if you were not going to then recopy from trunk? You might as
>well have done *only* revision 6715, and not bothered with 6713, and
>just continued branch development.
>
>Does this explain it better?
>
Yes it does, thanks! My only concern here is that in the middle of
rebranching I'd have to save and then reapply changes that didn't make
it to the trunk. I guess the decision on the merge strategy has to be
made on a per-project basis. In a corporate setting, I'd be reluctant to
use Subversion's rebranching, out of fear of losing unmerged changes
(it's more difficult to explain this to team members to begin with). So,
the question is, would I get a bigger database by using
"merge-mergeback" as opposed to "rebranch?" It looks like "yes."
Anyway, don't want to distract you all from more important things, sorry
about the noise on the list. I'll keep this thing in mind.
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> Apparently, sorry about that... I don't remember anything about this
> in the HACKING ;-).
It wouldn't be in there, it's a general branching technique not
specific to Subversion.
> > You just merged a bunch of changes into trunk. The procedure for
> > rebranching is:
>
> You mean, /from/ the trunk?
No, I mean *to* the trunk, in revision 6713.
Then, later, in 6715, you merged from trunk to branch, which is what
this thread is about.
> > 1. Delete the current Neon-0.24 branch, since all (or 90%) of those
> > changes are in trunk now.
> > 2. Create a new Neon-0.24 branch, based on the post-merge trunk.
> > 3. Port any remaining changes from your old Neon-0.24 branch to the
> > new one ("remaining" means ones that were not merged into trunk).
> > There's no point merging changes from branch into trunk, and then
> > immediately back into the branch again :-)... That doesn't get you
> > anything.
>
> I think it does, it does steps 2 and 3 for me. I have actually did the
> same thing in one step, `merge r X:Y trunk-url' (being in the branch
> WC), the way I'm used to in CVS :-) (maybe that was my principal
> mistake). Now, I'm not sure if this brings forth any database space
> issues, but with a single revision 6715 I have the same result as you
> would have, and I saved two revision numbers ;-).
There is no scarcity of revision numbers, the integers are infinite :-).
The more important thing is clarity. It's hard to tell why these
various copies are happening. By merging many changes from trunk to
branch, you create the misleading appearance of huge code churn --
whereas if you had just copied a new branch, there would have been one
"point of copy" in the history and it would have been very clear
what's going on (the number of paths changed in 'svn log -v' output
would be much lower, for example).
Look at it this way: why did you intially merge your changes into
trunk if you were not going to then recopy from trunk? You might as
well have done *only* revision 6715, and not bothered with 6713, and
just continued branch development.
Does this explain it better?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by mark benedetto king <mb...@lowlatency.com>.
On Tue, Aug 12, 2003 at 02:50:46PM -0400, Sergey A. Lipnevich wrote:
> I think it does, it does steps 2 and 3 for me. I have actually did the
> same thing in one step, `merge r X:Y trunk-url' (being in the branch
> WC), the way I'm used to in CVS :-) (maybe that was my principal
> mistake). Now, I'm not sure if this brings forth any database space
> issues, but with a single revision 6715 I have the same result as you
> would have, and I saved two revision numbers ;-).
You get one really big revision that way, rather than two very small ones.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6715 - in branches/neon-0.24
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
kfogel@collab.net wrote:
> sergeyli@tigris.org writes:
>
>>Log:
>>Merge back from trunk, r 6615:6714 incl.
>
>
> Sergey, can you describe your plan here? I think "rebranch" means
> something different to you than it does to me :-).
Apparently, sorry about that... I don't remember anything about this in
the HACKING ;-).
> You just merged a bunch of changes into trunk. The procedure for
> rebranching is:
You mean, /from/ the trunk?
> 1. Delete the current Neon-0.24 branch, since all (or 90%) of those
> changes are in trunk now.
>
> 2. Create a new Neon-0.24 branch, based on the post-merge trunk.
>
> 3. Port any remaining changes from your old Neon-0.24 branch to the
> new one ("remaining" means ones that were not merged into trunk).
>
> There's no point merging changes from branch into trunk, and then
> immediately back into the branch again :-)... That doesn't get you
> anything.
I think it does, it does steps 2 and 3 for me. I have actually did the
same thing in one step, `merge r X:Y trunk-url' (being in the branch
WC), the way I'm used to in CVS :-) (maybe that was my principal
mistake). Now, I'm not sure if this brings forth any database space
issues, but with a single revision 6715 I have the same result as you
would have, and I saved two revision numbers ;-).
Anyway, I can follow this recommended procedure from now on. I'm just
curious, why steps 1-3 instead of one step? Thank you!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org