On Fri, Mar 6, 2009 at 12:39 PM, <[email protected]> wrote: > > You're right. But if you open a new branch for each feature and commit > it back to trunk, you won't solve Jens' problem. >
He would need a branch for this, there is no argument from me. My workflow has branches for things that are still under development and they are removed when they are no longer needed. Your tagged release provides an archive you can go back to if you need to. > If you release a revision you should tag it. No argument. > If you release a main revision tag and branch it. Like that you're > able to fix bugs in this release (branch) and you may release another > revision from the branch without touching your main development tree > (trunk). Again, if it's being developed on, this should go in a branch to avoid breaking trunk. Under my workflow I'd branch the tagged version, work on it and retag it with an incremented minor number. I wouldn't merge it into trunk if it's from an old release (unless I should port that fix forward, which is a whole other issue). I rarely have to maintain old releases and it would bug the hell out of me to have a gazillion branches open if they aren't being actively developed. Tag them and forget about them until you need them again. Only keep things you're working on open in a branch. > Your way will leave the repository in a mess: No, my way will leave me with only the branches that are actively being developed. Again, keep it in a branch if you're still working on it. > You're at revision 100 in trunk. Than you notice that rev 50, which is > the last release you made had a bug, so you will check out the tag or > the trunk at revision 50. You solve the bug and than? > > Do you commit it to "tag"? > No, as my previous email noted, if you need to work on a tagged release, then you branch. And when it's fit to release, you retag it with a new version number. > If you commit the change to trunk you're messing up your > development-tree. In "tag" you would need another "tag", because "tag" is > an archive of your releases. So you couldn't commit the changes until > you're really going to release them. It's an old version so branch the tag and then retag with a bumped version number when it's fixed. If you no longer need the branch, remove it. > That's why I prefer the branch for main releases... I guess that's down to individual taste. As is it, from the state of the repository as I understand it (no tags), I'd do the following: 1. Track down the number of the revision you last released 2. Check it out at that revision into a second working copy 3. Tag it in the original repository, to save yourself having to do (1) again. 4. Branch it, so you can work on it 5. Fix, test, rinse, repeat. 6. Tag it, increasing the minor number At that point, if you're done with it, zap the branch. If you need to continue working on it, don't. Different workflows work for different people. It seems like your workflow is geared towards maintaining a number of product releases. My workflow is more engineered to developing a single site which constantly improves and which is always upgraded to the latest version. The only revisions I need to worry about are the one I'm working on and the one that's currently on live. Different strokes for different folks. --James ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [email protected] *******************************************************************
