The way I handle this sort of thing is with a combination of sharing and branching.
Let's say we're developing release 1.0 of the app. I'll make a SJ folder structure like this: MyApp/1.0 Then I'll put all of my code, starting out, under that 1.0 folder. Later on we go live with 1.0. But we want to maintain our code base so we can do maintenance releases and we want to begin work on 2.0. What we do is share the 1.0 folder into a new 2.0 folder. What this does is create a new folder structure like this in SJ: MyApp/2.0 Everything under 2.0 will be exactly the same as what's in 1.0. All of the folders will be the same and all of the files will be references to the exact same files as those under 1.0 (that's what we mean by sharing). Now, as we begin development in 2.0, we individually branch each file as we modify it (using the branch on checkin feature in most cases). This way, changes we make in 2.0 don't show up in 1.0 and we've always got a clean copy of 1.0. But if we make a change in 1.0 in a file that has not yet been branched, we don't branch it so that the change we make automatically gets propogated to 2.0. As we work for a while, many of our files will remain shared, but many will end up branched. We can continue this process into new releases, by sharing the 2.0 directory into a new 3.0 folder and so on. Labels fit in a little bit differently. I generally keep a top-level label in each of my "release" folders. I rebuild this every time a major chunk of functionality has been completed. This is how I personally fit shares, branches, and labels together to organize my build structre. One issue is that you end up with a lot of x.x folders after a while, but this is easy to take care of. Once you've got multiple release of your app, you can create a "current" and "archive" folder and just move the older release folders to the "archive" folder and keep only 2 or 3 release in "current". Hopefully this is helpful, Amit. Thanks for a good question. --Rob --- Shah Amit <[EMAIL PROTECTED]> wrote: > Hi, > > Please pardon my inexperience with branching/labelling. I have a set of > requirements and I am confused as to how I can use sourcejammer to help me. > > I have a project checked into sourcejammer. Let us say there are 10 files in > that. Now I want to "release" versions 1.0. Do some changes to the main line > of code and release 2.0, and similarly 3.0. However after 3.0 is released, I > might want to be able to go into 1.0 and change something in one of the > files (may be to fix some minor bugs) > > I tried to use label, but label doesn't let me change any files "in" that > label, except if I rebuild the label. However in my situation, I might > already be at version 3.0 and the code has drastically changed compared to > version 1.0 (The root of the problem is, the developement is far ahead of > the release schedule so we are releasing only small portions of whatever is > ready !!) > > I tried to use the branch feature, but it says I should share a file to > branch. Now I dont really need to share a file because all i want to do is > "release" ?? > > Please advise ... > > Thanks, > Amit > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > SourceJammer-users mailing list > SourceJammer-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sourcejammer-users > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ SourceJammer-users mailing list SourceJammer-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sourcejammer-users
