[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sticky tags
From: |
irina sturm |
Subject: |
Re: Sticky tags |
Date: |
Wed, 11 Jul 2001 16:15:01 +0200 |
address@hidden wrote:
>
> --- irina sturm <address@hidden> wrote:
> > address@hidden wrote:
>
> > > You will need to update -A on file_2 to commit it. If you didn't have to
> > > do
> > > this before commiting (and say the latest is 1.6), you would lose everyone
> > > elses modifications since version 1.3
> > >
> > > Once you do the update -A on file_2 you can continue with this scenario...
> >
> > I don't understand: if I am doing what you say,
> > I am not preserving myself of integrating the
> > other users' modifications before finishing
> > with my own, but just doing the same as for file_1.
> > In which case also I can't understand what the
> > sticky tag is useful for.
>
> you can run cvs update all day long and CVS will not bring in new changes for
> files checkedout on non-branch sticky tags, like your file_2. So you can
> continue to run cvs update on file_1 and file_2 and cvs will keep file_2 at
> the
> revision you want it, while updating file_1 to the lastest revision.
>
> But when you want to commit file_2, you have to merge in (update -A) changes
> commited after revision 1.3, before you checkin the file. This requirement has
> nothing to do with the stickyness of the file (although you can't commit a
> non-branch sticky tag even if the revision you have is latest on the branch,
> which off the top of my head doesn't make sense, but I could be overlooking
> something), it has to do with the fact the version of the file you are working
> on is not the latest on the branch. This requirement to update before
> commiting
> exists for non-sticky checkouts and checkouts on the latest on a branch as
> well
> (when you working revision is not the latest).
>
> this is a fundamental process in all version control tools. (forget about
> stickyness for a minute) If you checked out version 1.3 of file_2, and edited
> it. The where able to commit your working copy to the repository (where for
> sake of example, the lastest version of file_2 is 1.6), your commit would
> delete the changes made in 1.4, 1.5 and 1.6.
>
> Mark
>
I completely agree with what you are saying.
What I was trying to figure out was the
utility of a non-branch sticky tag, and to
check it with other people more experimented
than me in using CVS. The scenario I proposed
was something like: should this be something
for which the sticky tag is useful?
Otherwise I agree that I need to do update -A
in order to integrate all changes made in
between.
Thanks, I think I might have got an answer
to my question,
Irina.