> > 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
> way.
Like I said, we don't even have a path named "trunk".
The paths to the above versions in the repo would be like:
svn://server/repo/project/v1.0.0
svn://server/repo/project/v1.0.1 (this was copied from the 1.0.0 path)
svn://server/repo/project/v1.0.2 (this was copied from the 1.0.1 path)
On my dev machine I have a dev root in my Users folder named "development". I check out each version to that. I DON'T use switch. I think it is too easy to forget which current version you are switched to. So, I would have all three version check out like this:
Development\Project-v1.0.0
Development\Project-v1.0.1
Development\Project-v1.0.2
Weekly we do a merge. Let's say the oldest release with changes in 1.0.0. So, I would do something like:
cd Development\Project-v1.0.1
svn merge svn://server/repo/project/v1.0.0 (I actually use TortoiseSVN but I think that is the command line version)
I resolve and conflicts, build, test, commit. Once the build server gives me a green build I move to the next version.
cd Development\Project-v1.0.2
svn merge svn://server/repo/project/v1.0.1
Rinse and repeat.
Notice, I didn't specify and ranges. svn figures out what revisions from the source path have not yet been merged in for me.
BTW: Just as an aside we do have a branches folder in the project and this is where we put feature branches. Although we don't use them too often, we have used them.
BOb
Received on 2011-04-20 16:41:13 CEST