You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Eric Sammer <er...@ineoconcepts.com> on 2003/10/11 04:36:50 UTC
Effects of merge on added files
All:
I'm a bit of subversion noob (but a cvs veteran) so I apologize in
advance. I am used to creating a trunk with tags for stable releases and
having a branch off of the trunk for each development version, merging
into trunk along the way (i.e. "average" development ala K. Fogel's CVS
black book).
I have a working directory like:
ProjectName/
trunk/
Directory_A
dev_0_01/
Directory_A
A_file_added_in_branch.c
If I try the following to merge the branch back into trunk:
cd ProjectName/trunk
svn merge ../dev_0_01@HEAD ./@HEAD
I get errors such as:
Skipped missing target: A_file_added_in_branch.c
I understand that this file doesn't exist in trunk yet and is therefore
not under revision control, but the docs imply that merge works like
diff. I assumed that, like CVS or diff/patch, missing files would be
added. Is this assumption incorrect? I can't find any additional info
that directly describes merging a NEW file. If I do the following:
esammer@ripley trunk $ cd ProjectName/trunk
esammer@ripley trunk $ svn diff --old ../dev_0_01@HEAD --new ./@HEAD
I get the unified diff output that I would expect.
I'm quite sure I've missed something because even in alpha stage,
subversion surely must be able to merge new files as well as changes in
existing files, correct?
I've read the svn book (especially chap. 4) through as well as the guide
for cvs users and found nothing that hits this dead on.
To clarify, in cvs, I would do:
(In working directory root ProjectName)
cvs tag -b DEV_0_01
cvs update -r DEV_0_01
touch A_new_file.c
cvs add A_new_file.c
cvs commit -m 'added new file'
cvs update -j DEV_0_01
cvs commit -m 'merged DEV_0_01 into trunk'
Thanks in advance, and apologies all around for the noob question.
--
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
On 11 Oct 2003 08:22:59 -0500, "C. Michael Pilato" <cm...@collab.net>
said:
> Eric Sammer <er...@ineoconcepts.com> writes:
>
> > C. Michael Pilato wrote:
> > > You want:
> > > svn merge ./@HEAD ../dev_0_01@HEAD
> >
> > I can honestly say that I would have NEVER guessed this was it. To be
> > honest, I find the merge syntax quite a bit convoluted. I'm sure this
> > is merely a product of alpha status, but maybe something that requires
> > a second glance.
> >
> > Either way, thanks for the info (and it does work with this syntax).
>
> Well, the syntax is pretty straightforward in the general case. It's
> like diff, where you have a "from" and a "to", only it also has a
> third argument for where to apply that diff. But we do have some
> shortcuts to that cmdline that, to be honest, I'm never quite sure how
> to use.
>
You know what ? I used the /path@X /path@Y syntax only once. And I did
not understand completely. So, I switched to svn merge -r X:Y /path, and
since then, my merges have been working wonderfully ;)
Thanks !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Sammer <er...@ineoconcepts.com> writes:
> C. Michael Pilato wrote:
> > You want:
> > svn merge ./@HEAD ../dev_0_01@HEAD
>
> I can honestly say that I would have NEVER guessed this was it. To be
> honest, I find the merge syntax quite a bit convoluted. I'm sure this
> is merely a product of alpha status, but maybe something that requires
> a second glance.
>
> Either way, thanks for the info (and it does work with this syntax).
Well, the syntax is pretty straightforward in the general case. It's
like diff, where you have a "from" and a "to", only it also has a
third argument for where to apply that diff. But we do have some
shortcuts to that cmdline that, to be honest, I'm never quite sure how
to use.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by Eric Sammer <er...@ineoconcepts.com>.
(Sorry for the late reply - Handling clients...)
Ben Collins-Sussman wrote:
> No, this syntax is not a product of alpha status. And I'm ready to
> debate anyone who thinks it's not perfectly precise and useful. :-)
Ok, how about a rephrase... ;)
While precise and useful, maybe it's not "quickly grok-able?" I was
generally surprised (or maybe just too used to cvs) at not taking the
"tip" of the branch (i.e. latest branch revision) and merging it into
the latest trunk revision. Unless I'm in need of a thought process
re-train, this is what I was looking for. In retrospect (and
post-explanation) the svn method of "from beginning of branch to tip
into trunk" now makes sense, but still seems a bit cumbersome.
It could also have something to do my (mental) dependency on user
defined keyword style tags for the head of the branch and the tip. I'm
quite sure that once I've really thought about it (and purged cvs from
the grey matter) it will be dead on clear. For now, I've had to export
the code base and pull it back into cvs as I don't have the time on this
project to fight with it. Even thought the command line works, I'm not
comfortable with *why* it does (in the theoretical sense) to continue
with it in production. Of course, this is more just feedback than
anything else and may not be worth a <insert small thing here>.
That said, I long for svn's atomic commits... ;)
> Even Mike's suggestion up there is the wrong answer.
>
> To merge a branch back into the trunk, you compare the *root* of the
> branch with the *tip* of the branch, and merge the resulting diff into
> a trunk working copy. By comparing the root and tip of the branch,
> you're describing *only* those changes that took place on the branch.
> That's what it means to "merge branch changes" into trunk.
But in the (arguably) most generic and common usage of branches, doesn't
one always wish to merge the entire (head to tip) branch into the
destination, be it trunk or otherwise? This seems to be what cvs does in
comparison to svn, if I'm getting what you're saying. And, if that is
the case, wouldn't it be a bit more intuitive to default to such
behavior and allow for '--form <revision> --to <revision> <wc>' style
syntax for those (again, arguably) rare occasions where you wish to
merge a portion of the branch?
(Disclaimer: I'm really not just trying to be difficult. I promise.)
Of course, the defaulting to head-to-tip-into-destination as I mentioned
would require an update of the branch prior to the merge if the trunk
has changed, but that is what I would want to do in 99.9% of my projects
anyway. Other's mileage may vary.
> If you compare the tips of branch and trunk, you're going to get a
> diff that you don't want: you'll be specifying "all branch changes,
> plus removal of all trunk changes that took place since the branch was
> made."
Right. See, this is what I would have expected.
> There's even a whole section in chapter 4 that specifically addresses
> this scenario:
>
> http://svnbook.red-bean.com/html-chunk/ch04s03.html#svn-ch4-sect-3.3
I apologize; you're 100% right. I read this section completely wrong. It
certainly is spot on with regard to this.
> This is not a matter of confusing syntax; it's a matter of
> understanding which trees to compare. The only way things can (and
> will someday) get better, is the day Subversion automatically
> remembers the revision in which a branch was created. At that point,
> we can invent a new 'automerge' syntax (or something) that literally
> looks something like "svn automerge branchURL wc", and means "merge
> this branch into my working copy, you figure out what to do". But
> until we develop such intelligent merging technology, you're stuck
> having to understand exactly which trees to compare, and why.
It was the why that I wasn't getting. Am I completely wrong about the
way cvs handles this? I almost *never* make changes to the trunk when a
branch is "moving" like this. Bug fixes found are usually the only
exception and in that case, the bugfix branch is merged back to trunk,
the dev branch is updated from trunk, and when dev is complete, it is
merged back into trunk.
Ex: (pardon big fixed font ascii art)
#1 #4 #5
|branched for dev |updated |merged back to trunk
| | |
dev +--- dev_0_01 ------------------+--------+
trunk --+----------+------------------+-+--------+---+------>
bugs +-bug_fix_1234-----+ |final_0_01
| | #6
|branched bug fix |merged to trunk
#2 #3
That said, it's certainly possible I'm just thinking too hard about it. ;)
> It's
> not rocket science, honest. :-)
At 2:07AM EST it sure is. :)
Thanks to all who took the time to answer even though it was, in fact,
in the very chapter I read 9000 times.
--
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by Ben Collins-Sussman <su...@collab.net>.
Eric Sammer <er...@ineoconcepts.com> writes:
> C. Michael Pilato wrote:
> > You want:
> > svn merge ./@HEAD ../dev_0_01@HEAD
>
> I can honestly say that I would have NEVER guessed this was it. To be
> honest, I find the merge syntax quite a bit convoluted. I'm sure this
> is merely a product of alpha status, but maybe something that requires
> a second glance.
No, this syntax is not a product of alpha status. And I'm ready to
debate anyone who thinks it's not perfectly precise and useful. :-)
Even Mike's suggestion up there is the wrong answer.
To merge a branch back into the trunk, you compare the *root* of the
branch with the *tip* of the branch, and merge the resulting diff into
a trunk working copy. By comparing the root and tip of the branch,
you're describing *only* those changes that took place on the branch.
That's what it means to "merge branch changes" into trunk.
If you compare the tips of branch and trunk, you're going to get a
diff that you don't want: you'll be specifying "all branch changes,
plus removal of all trunk changes that took place since the branch was
made."
There's even a whole section in chapter 4 that specifically addresses
this scenario:
http://svnbook.red-bean.com/html-chunk/ch04s03.html#svn-ch4-sect-3.3
This is not a matter of confusing syntax; it's a matter of
understanding which trees to compare. The only way things can (and
will someday) get better, is the day Subversion automatically
remembers the revision in which a branch was created. At that point,
we can invent a new 'automerge' syntax (or something) that literally
looks something like "svn automerge branchURL wc", and means "merge
this branch into my working copy, you figure out what to do". But
until we develop such intelligent merging technology, you're stuck
having to understand exactly which trees to compare, and why. It's
not rocket science, honest. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by Eric Sammer <er...@ineoconcepts.com>.
C. Michael Pilato wrote:
> You want:
>
> svn merge ./@HEAD ../dev_0_01@HEAD
I can honestly say that I would have NEVER guessed this was it. To be
honest, I find the merge syntax quite a bit convoluted. I'm sure this is
merely a product of alpha status, but maybe something that requires a
second glance.
Either way, thanks for the info (and it does work with this syntax).
--
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Effects of merge on added files
Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Sammer <er...@ineoconcepts.com> writes:
> If I try the following to merge the branch back into trunk:
>
> cd ProjectName/trunk
> svn merge ../dev_0_01@HEAD ./@HEAD
>
> I get errors such as:
>
> Skipped missing target: A_file_added_in_branch.c
Well, Eric, I am not a Subversion "noob", but I too would complain
about such behavior. Like you, I've always thought of merge as "diff
applied to files instead of to stdout".
Now, I can understand doing this if we receive as part of the merge
modifications to a file that doesn't exist, but why would we ignore
the addition of a file that doesn't exist?
[ C-Mike goes to see what we really do. ]
Hm. I'm not seeing what you're seeing.
If I copy a directory, commit, add a file to that copy, commit, and
then merge from the copied dir to the original, I get a new file
marked for addition.
Ah, ah. I see.
I did:
$ svn merge -r N-1:N ../branch .
where N was the revision in which I added the new file. But when I
did:
$ svn merge ../branch@HEAD ./@HEAD
I got the "skip" notification.
I think I know what's happened here. You're commandline is not quite
right. What you are asking for is the diff between the tip of your
branch and the tip of your trunk, which actually would be the
*removal* of anything added to the branch.
You want:
svn merge ./@HEAD ../dev_0_01@HEAD
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org