Many times I commit a batch of files that are
scattered about a large tree within the module.
It is nice to be able to find & select the files to
commit all together by doing commit on the top level
directory of the module. However, once that is done
I would like to add a new tag to those same files for
the latest revision, but now that they are commited
there is no easy way to select them again for adding
a tag!
Just like a comment can be added to all the files for
a commit, there should be an option on that same
dialog for a tag to add to those files. The tag
should be applied to the recently commited revision,
so it could be done after all commits or alternating
for each file in the batch (CCCCTTTT vs. CTCTCTCT).
The imporant part is that is is done as part of the
batch operation.
Logged In: YES
user_id=382855
Why do you want to tag only the committed files, and not all
the files?
Logged In: YES
user_id=1182030
Because the module itself is a web site that contains
several thousand files and it seems excessive to tag ALL
of them if only 10 or 15 are updated for a specific
project.
Also, when it comes time to do an export for release to
production environment, other (newer) revisions of
unrelated files may have already been released.
Example: Project A completes development before project
B, but is released (via export) after project B, the
release of project B is lost. This assumes disjoint file
lists for A & B. If there is overlap in the files, then
that's a release dependency in itself (not a CVS issue
though).
Logged In: YES
user_id=933573
Originator: NO
I vote for this RFE
It would be useful to tag & commit because in this way you can identify the list of files affected by a bugfix.
It would be even more usefull to have a "view by tag" showing the list of file by tag.
Logged In: YES
user_id=382855
Originator: NO
Why is it that you want to tag only the changed files?
Logged In: YES
user_id=1182030
Originator: YES
I think a better way to explain it is that it provides a way to define a logical group of files within the module. This is a grouping based on their relation at a point in time rather than location in the file tree.
It's not terribly useful when it's a source code tree for an app that is compiled & packaged in its entirety for a release. But who said CVS has to be limited to full-tree-build projects?
Another way to look at it is defining sub-modules, but these sub-modules may overlap one another, so it is not practical to just divide up the module into multiple parts.
Oh, and this grouping tag would be a tag given to the sub-set of files in addition to the one given to the entire module after the commit to denote a "release" version or whatnot.