[cvsnt] Re: commit followed by a tag

[Gerhard Fiedler]

Matt Schuckmann wrote:

> This whole discussion has brought us back to my origonal point, why can't
> you tag when you commit? Tony said it doesn't make sense, he also said that
> to use tags to discribe change sets is incorrect.

This is about what Bo said. It doesn't really help you much to tag a few
files; when you later retrieve this tag, you can't do much with it, as all
the other files are out of sync. That's why you usually will tag all files
required to do a build. 

Which is not that much of a problem. Your developers need to tag before and
after their feature implementation. What they have done is the difference.
Some files will have both tags on the same revision; these don't contribute
to the difference.


But I still think tags are not really a good choice for what you want.
Maybe branches for every feature or fix do it better:

- Developers can do intermediate commits. This gives them backup safety and
history. It sometimes happens that during a feature implementation you want
to look back what you had a few days ago. Branching gives you this
possibility: you can commit incomplete code without disturbing anybody
else.

- You have a complete documentation where the feature development started,
where it ended and what got changed underway. Retrieving the difference
between start and end is more straightforward than without branches. 

- You get your tags almost the way you describe them. Every feature
implementation sits on a branch with the feature name in it, like bFUNC345.
But rather than a single point of a few files, this is a full branch and
you can go back and see what has happened there, from start to end.

- Merging the branches into a semi-stable development base can be done in a
more controlled and flexible fashion. You can even let a branch sit for a
while if you think it's not a good time to merge it in.

> Yes every later feature is dependent on earlier efforts but only where those
> efforts overlap, in most cases they don't overlap. 

If the changes in various branches don't overlap, merging them back in
should be rather straightforward.

> It would be nice if developers could base thier working sandbox on a known
> good, at least marginally functional, sandbox.

This shouldn't be a problem either way. You just have to make sure someone
coordinates what gets merged into that branch (be it a dedicated
"development base" branch or the main branch). 

Gerhard