[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: duplicate merge conflict

From: Daniel Walter <d2walter_at_hotmail.com>
Date: Wed, 20 Apr 2011 10:25:51 -0400

> If you are merging everything in there is no need to worry. That is the
> point of merge tracking. It will determine what has yet to be merged and
> select the correct revisions.
> Here is how we have our repo set up... rather than using trunk. We find it
> makes things easier.
> We basically "branch" when we start on a new release version. So we have
> something like this:
> 1.0.0------------
> \
> \
> 1.0.1 +-------------
> \
> \
> 1.0.2 +--------------
> We release from the version path (branch). Any hotfixes for that version
> are done on that branch. Then they are merged forward "up" version. So we
> merge a change made on the 1.0.0 to 1.0.1 then to 1.0.2 and forward. We
> "try" to only have our current release (1.0.1) and one back (1.0.0) in
> maintenance and then the in dev version (1.0.2). Of course, you always
> have that one client that doesn't want to upgrade and sales/support
> insists we do a fix... but we still just merge it up versions until it is
> merged into the unreleased dev version.
> BOb

This seems to describe my scenario quite well. What command do I use to
merge. Also, how is your development tree structured. I would think that
1.0.2 would be the trunk in this scenario, but you don't have it drawn that

Received on 2011-04-20 16:26:24 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.