> > 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