Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Glen Starrett" <grstarrett at cox.net> wrote in message news:d4hqie$8iv$1 at paris.nodomain.org... > Matt Schuckmann wrote: > > No I don't want to only checkout the changed files but I do want to be > > able to identify what was changed with respect a task, yes if it's on a > > branch this is pretty easy but what if it's not on a branch? Further > > more I want to be able to bring the changes from a few "approved" tasks > > together to create a new Release Candidate build how would one go about > > doing that? > > Why wouldn't they be on a branch? I would assume that would be required > by your process from what you've been talking about. The release > manager would have to merge all the "approved" tasks onto HEAD (or onto > a RC branch) and then handle any conflicts there. Integration testing > should be part of any project schedule. I was just trying to be open to various solutions, from what your saying the only way to go is to use branching. > > > > You know what I think your right, when I tested this before I forgot to > > include the -kk option. When I just retested it I included the -kk > > option and I didn't have the problem, well the duplicate revision does > > get created on the branch but not on the trunk cool. > > Thanks for the info. > >> Matt Schuckmann Wrote: > > > > Plus while I was testing it this time I noticed the -M option (floating > > branch) to the tag command, the floating branch is pretty much exactly > > what I was looking for. > > > > I think that floating branches per task are pretty much going to do what > > I want. Unless any of you know of any peculiarities with floating branches? > > Glen Starrett Wrote: > You should make sure you think through using a floating branch. Look > back through the archives here and see the discussion around them -- > they can break your sandbox unexpectedly. > > Example in a nutshell: You need to update f1 in foo.c on a branch, so > that locks the place where foo.c is branched from. It happens that > foo.c uses a f2 in bar.c. However, bar.c is still floating -- so when > someone else merges a version to MAIN that alters the way that f2 works, > your sandbox is now broken until you merge in the latest changes into foo.c. > > Naturally, it is all dependent on how your project's dependencies are > set up and how coordinated your developers are... YMMV. > By "break your sandbox" you mean prevent it from building not break the repository right? I understand your example and how it could cause problems and it is something to consider, I don't think that it will cause to many problems as our code is spread out enough and people generally work in pretty diverse area's of the code so people ususally don't colide. By using the floating branch tag we almost get the best of both worlds 1. The developers new code is kept issolated on the branch and the branch is really only those changes made by the developer. 2. The developers get the lastest stable code from the release code line whenever they update thier sandbox. The only thing they don't get is any changes made on the release code line in files they have modified on the branch, to get those changes they must do an explicit merge from the parent to the branch. I guess what I really want is a floating branch tag that only floats when you merge the parent onto the branch, that sounds a little more usefull than the way it's implimented now, it sort of prevents unexpected breaking and it helps to keep the task branch to purely task releated changes. What do you think? Thanks, Matt S.