Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message
news:hrtwunhqbcbq$.1bgbf624ncw1a$.dlg at 40tude.net...
> Matt Schuckmann wrote:
>
> >> You seem to be stuck on the consept that tags are only usefull for
> >> indentifying a complete build, I would argue that that's not true. They
> >> can also be use full for indentifying a subset of the build that you
> >> may want to keep track of, or be able to checkout easily, etc.
>
> "They can be useful": Kind of, and kind of not.
>
> When someone checks out such a tag, the result is of a very limited use.
> You can't build it because all the other files are missing. So you can't
> even verify that it works. If you check out the other files to build it,
> you don't know which revision of the other files to get. The tagged files
> usually depend on interfaces in the other files, and if these change, the
> tagged files would have to change, too. This is why Bo said that a tag
> usually needs to tag everything that's necessary for a build, because even
> though you maybe changed only three files, the changes make only sense in
> the context of the other thirty files as they were at the time you changed
> the files.
>
I think that it would be a safe assumption to first checkout, or update to,
the last tagged build before the tagged subset of files, this has worked
just fine for us for 2 years. Or maybe you don't really care, maybe the
changes are self contained and you don't really care what version the rest
files are at just so long as they work.
> Then there's the difference aspect. You can say that the tag allows you to
> create the difference, what got changed by the fix. But in this case you'd
> have to have a tag from before the fix and one that marks the end of the
> fix. How would this work with an automatic tagging feature? You still
would
> have to tag the whole repository before you start working on the fix. Or
> you would have to remember to do that with every single file you start to
> work on -- dangerous, at least. Just an option for commit that adds a tag
> doesn't give you this. So the solution for this would also be to tag the
> whole set before and after the fix, not individual commits.
>
If your working in the paradigm I described before the tag before the
changes would be the last build tag or the last fix tag. Or, maybe you don't
want the defferences maybe you just want to keep track of those revisions of
the subset of files because you know they are special and you've got an
unhealthy fear of branches.
Oh and wouldn't it be cool if you could if you could give checkout or update
several tags and it could automatically figure out what set of file
revisions is the most update given those tags.
for example given the repository with the 3 files:
display.cpp
rev 1.1: BLD1
rev 1.2 FIX3
display.hpp
rev 1.1: BLD1
color.cpp
rev 1.1:
rev 1.2: BLD1
rev 1.3: FIX3
rev 1.4: FIX4
and the command:
cvs checkout -r BLD1 -rFIX3
you would get
display.cpp rev 1.2
display.hpp rev 1.1
color.cpp rev 1.3
We actually implimented this with some scripting and the rcs rlog feature in
MKS.
I know that I could impliment the same thing with cvs but I'm, thinking that
it would be better to go with some branching.
> (This could be different if cvs had the option to assign a single symbol
to
> various revisions of a file. Then you could mark all commits for a feature
> or fix with that symbol, and the complete change set for that feature
would
> be the addition of all commits with that symbol. This could work, but it
is
> not how tags work in cvs. This can't really be done with cvs so far, in
> this way, to my knowledge.)
Hey you finally got it this is exactly what I want and yes CVS can almost do
this it just takes a minimum of two commands to do it, maybe 3 because I
don't think that commit displays the new revision numbers added.
For example say that logdisplay.cpp is at version 1.3, to commit changes to
logdisplay.cpp and label (tag) the revision with NEWTAG right now I'd have
to do the following (assuming that I know that the revision of
logdisplay.cpp is going to be 1.4):
cvs commit -m"" -f logdisplay.cpp
cvs tag -F -r 1.4 NEWTAG logdisplay.cpp
Why not just add a couple of options to the commit command and make it 1
command, like everybody else does. It's not anything ground breakingly new.
Forget why I want the tag there and what I'm going to do with it. You seem
to be hung up on the way your used to working with CVS.
>
> So however you look at it, an auto-tag option for commit seems not to make
> a lot of sense, considering how cvs handles tags.
>
I still disagree.
>
> > Hey, there could even be another option for the commit command, call it
> > the -b option, which creates a branch with the provided tag name. This
was
> > also an option of ther CM systems I've used.
>
> Actually, the best thing is to create the branch before starting to work
on
> the fix, and create it on the complete source. (Of course there are
special
> considerations for very large projects; then you probably should create
> pseudo-independent sub-projects.)
>
>
> > All I'm saying is that if you want to use tags or branches or bug id's
to
> > create a subset of your files you should be able to create (or add to)
that
> > subset at the most logical point i.e. when you commit.
>
> This is not really the most logical point for me, at least for tags and
> branches (no experience with bug ids). IMO the most logical points in the
> lifetime of a fix or feature implementation are when you start working on
a
> feature or fix (that is, when you start diverging from the current stable
> state), and when you have a working implementation (that is, when you
think
> you have reached a stable state again). Individual commits are only
> arbitrary points in between those two.
>
Actually the first time you check in (commit) is the point at which you
really start to diverge from the stable build and you may or may not revisit
that file. If you do you just move the tag/label/symbol/bugid up to the next
revision, it's sort of like a floating label (but not really). Further more
you may decide to abandon the changes before ever commiting so then in your
senario you've got a dead branch/tag sitting out there taking up space. Why
go through the extra work to create a tag/branch across the entire
repository when all you really care about is just a few files.
Matt S.
> Gerhard