Re: Effects of merge on added files

(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