Hey Chris,
> > | g) [mandatory if e) was done] tag the main trunk (cvs tag
> > 2.3.28 for
> > |example); this is also useful to track which files and when have
> > |been merged
> > |and if something went wrong we have tags to figure it out.
>
> I don't think this is needed - tagging of the main trunk -
> cant this be done
> by date just as easily. Just tag it when we want to make a release.
We found it very useful to understand what happened to the main trunk (just
for this, I agree that can be skipped, but tags are very cheap in CVS,
soo...). For example:
Say you have on main trunk revision 2.3.28 of a file with tag 2_3_5.
Now you merge a patch from the branch, you'll have revision 2.3.29 of that
file, and you don't tag it.
Someone checks in revision 2.3.30, and tags it 2_3_6
Now you want to know the history of changes on that file; if you see a tag
like "Merged_with_2_1_4" you clearly understand what happened.
Anyway, it's not necessary as the tag on the branch, which is fundamental
for incremental merges.
> > |3) Creating a binary (IMHO this is best done from branches)
> [snip]
>
> Now this seems like overkill - the branch is tagged already -
> so why not
> just use that for the build?
In which sense the branch is tagged already ?
Say you want to check out the source corresponding to the binary... you must
have a tag for that, and it cannot be the same as pre-release - what I
called 2_1_28 (otherwise you don't know which one to choose, right ?).
Cheers,
Simon
