I've thought about that but SF does do a really good job at protecting the data and keeping the servers running. Unless somebody could show that level of support I'm not sure it would be a wise decision to move from it.
-----Original Message----- From: Ben Lowery [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 12:33 PM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] NAnt 0.9 refactoring (long) the other crazy option here would be to setup and maintain a perforce server. you can get a free license for open source projects from perforce for an arbitrary number of users. you just need someplace to host the perforce service... --b ----- Original Message ----- From: "Jordan, Tom" <[EMAIL PROTECTED]> To: "'Shaw, Gerry'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, August 14, 2002 2:37 PM Subject: RE: [nant-dev] NAnt 0.9 refactoring (long) > Hi Gerry: > [I'm putting this on the list in case someone else > would like to know --thank, tom] > > > From: Shaw, Gerry [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, August 14, 2002 12:23 PM > > > > In your last email you seemed in favor with the /nant/master and > > /nant/version/0.7/ type cvs repository structure but in your earlier > > message you seemed against it. > > I am against it. > > > I must confess that I've never done a branch in CVS. Is it very > > different from Perforce? Have you used Perforce branching? > > I have not used Perforce, but I hear many good things about it from > people like Brad Appleton. A lot of SCM people that have used Clear > Case from Rational like Perforce. > > > If I want to work on a master and a couple of stable branches (to > > fix bugs) using CVS how would I do that? > > CVS works by maintaining a directory structure of RCS files. You find > this in the CVS repository. > > In CVS, there are two basic tag types: Branch tags, and regular. > > Every CVS project has a hidden branch tag called HEAD. > This is your mainline development branch. > HEAD always tracks the tip of the mainline; so > "cvs co nant" does the same thing as "cvs co -r HEAD nant" since HEAD > is the default branch. > > Now let's say I create a release, so I make a regular tag > in my working space. "cvs tag nant-1_0-build-1 *" > This allows me to go to any empty directory and check out this exact > source collection at anytime down the line. "mkdir temp; cvs co -r > nant-1_0-build-1 nant" > > This allows me to reproduce a build at anytime as long as nobody goes > and force changes the tag. "cvs tag -F nant-1_0-build-1 *" > > Now if you went through 8 development builds and build 8 becomes the > one that passed QA controls and is released to the public. I can then > create a maintenance branch off of build 8. "cvs rtag -b -r > nant-1_0-build-8 nant--1_0--main--br nant" > where: > rtag -> work on repository instead of current workspace > -b -> make this a branch tag instead of a regular one > -r <tag> -> reference this existing tag > <br-tag> -> create this branch tag > <module> -> on this defined CVS module > > You can do the same thing by, > "mkdir temp; > cvs co -r nant-1_0-build-8; > cvs tag -b nant--1_0--main--br *" > > Now I can go to the root of my workspaces and check out both the > mainline "HEAD" branch and the maintenance branch. > "mkdir ws; > mkdir mainline; cd mainline; cvs co nant; cd ..; > mkdir 1.0; cd 1.0; cvs co -r nant--1_0--main--br nant; cd ..;" > > The main difference between regular and branch tags: > 1. Branch tags always track the tip of the branch they define. 2. You > can check in on a branch tag. 3. Regular tags are fixed. > 4. You can not check in to a regular tag reference. > > When you create a branch in SourceSafe, it copies the entire project > structure into various different parts of it's repository. The result > is that you quickly bloat the repository when you do alot of > branching. > > When you create a branch in CVS, it just uses RCS version numbering to > track the branches within the target file. Thus, while the underlying > RCS file grows with each branch you do, there is not a whole sale copy > of the repository. > > The result of this is that my development workspace will look similar > to what you are proposing. However, the repository will remain > relatively small and not require more and more hard drive space for > the repository. > > The reason that you use branches for maintenance only and not for > forward development is because CVS slows to a crawl when the size of > the branch becomes huge. The same thing happens the further you > branch from the HEAD branch. > > This is one reason that change-sets haven't really caught on when > using a CVS repository. > > Change-Sets is another thing that I think Perforce has that is tedious > to implement in CVS. > > Now say you have fixed a couple of bugs on a maintenance branch and > you want to roll your changes back into the mainline of development. > > The strictest merge algorithm that I have seen involves > three regular tags: > 1. Checkout the maintenance branch and fix the bugs. > 2. Check your fixes in on this branch. > 3. Create a regular tag on this branch to represent the merge point. > eg: cvs tag nant--1_0--main--mp-20020814T1400 * > 4. Checkout the mainline branch. > 5. Create a regular tag on this branch to represent the before picture. > eg: cvs tag nant--1_0--main--mp-20020814T1400-before * > 6. Merge the delta from the maintenance branch onto the mainline. > eg: cvs up -j nant--1_0--main--base -j nant--1_0--main--mp-20020814T1400 > * > 7. Correct conflicts and do a successful build. > 8. Create a regular tag on this branch to represent the after picture. > eg: cvs tag nant--1_0--main--mp-20020814T1400-after * > > Now you have the ability to roll back to before and after the merge > operation. > > One note: > On merge operations, only go back to the last merge point on the > branch. If you don't you will increase the number of conflicts that > you will have. > eg: > > ----mp(1)----mp(2)--- > > when merging mp(2) do: > cvs up -j mp-1 -j mp-2 * > instead of: > cvs up -j mp-base -j mp-2 * > > I hope this helps, > -- Tom. > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > Nant-developers mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers > ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code1 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
