Re: Sticky tags

[Mark]

--- 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


> What I was expecting actually is that if, for
> example, v 1.5 is the last one for both file_1
> and file_2, and I decide to work on the files
> as above, I should do:
>       cvs co file_1
>       cvs co -r1.5 file_2
> and then apply my scenario, and thus I will
> keep up with the others' modif on file_1, 
> but not on file_2 until I decide to do
> 
>       cvs update -A file_2.
> 
> Is that more clear?

Yes that is correct. But you cannot commit file_2 until you do the update -A

> Irina.
> 
> 
> > 
> > > cvs commit file_1 file_2
> > >
> > > # edit file_1 and file_2
> > > cvs update file_1 file_2
> > > cvs commit file_1 file_2
> > > ...
> > >
> > > And when I want to integrate others' modifications
> > > on file_2, I do:
> > >
> > > cvs update -A file_1 file_2
> > > cvs commit file_1 file_2
> > >
> > > Is this the way it works (are my suppositions
> > > and scenario above right)?
> > >
> > > Thanks,
> > > Irina.
> > >
> > > _______________________________________________
> > > Info-cvs mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/info-cvs
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> 
> -- 
> ===========================================================
> Irina STURM
> Functional Verification Center of Competence - CMG 
> STMicroelectronics, 9 chem de la Dhuy, 38240 MEYLAN, FRANCE
> Phone: (+33) (0)4 76 58 68 90, Fax: (+33) (0)4 76 58 40 11
> E-MAIL: address@hidden
> ===========================================================


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/