CVS remove sticky tag without update

Question

CVS is really driving me crazy!

Is there any trick to remove sticky tags without updating file contents? I know of 'cvs up -A' but this also changes my files.

Or the other way round: Is there any way to update a complete directory to a previous date without setting sticky tags in the first place?

Background: I use a working copy that is versioned both with CVS and HG and I messed it up, so I wan't to go back to the latest point where it was in sync and then check what would come in from CVS.

thanks and regards.

Rubinstein

I also, right now, am versioning with both HG and CVS (HG for my own convenience, CVS because it is legacy project). I have done similar with HG/GIT/CVS/RCS/BZR/... We need to find,. or write up ourselves, a how-to for such multiple VCS tracking. – Hopper

Answer 1

This may depend on your version of CVS, and comes with the caveat that it's not supported, but I used to manually remove the sticky tag from the CVS/Entries file. I did this a lot when I wanted to roll back my working version to a past version but avoid the sticky tag so that I could just update normally when I'm ready.

First, just update the file to the version you want from the repository. For cleanliness I was in the habit of removing my local copy first.

rm myfile
cvs update -r 1.20 myfile

This will of course leave you with the sticky tag.

cvs status myfile
===================================================================
File: myfile      Status: Up-to-date

   Working revision:    1.20
   Repository revision: 1.20    /cvsroot/myproject/myfile,v
   Sticky Tag:          1.20
   Sticky Date:         (none)
   Sticky Options:      (none)

The sticky tag is stored in the CVS/Entries file in the last field. If you look at CVS/Entries with a text editor and search for your filename, you will find this:

/myfile/1.20/Thu Nov  6 18:22:05 2014//T1.20

The T1.20 at the end represents the sticky tag. You can simply remove it, leaving the line:

/myfile/1.20/Thu Nov  6 18:22:05 2014//

Now, the sticky tag is gone. You're in the same state you'd be in if someone had checked in a new version and you simply haven't updated yet.

cvs status myfile
===================================================================
File: myfile      Status: Needs Patch

   Working revision:    1.20
   Repository revision: 1.21    /cvsroot/myproject/myfile,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

Once you verify that this works on a single file, and get brave, you can do the whole directory at once if you want to, using your favorite tool (perl, awk, etc) to modify every file in the CVS/Entries (or only those lines you wish to modify). You should use caution of course. I use perl, and keep a .backup to fall back on in case of any trouble:

perl -pi.backup -e 's|//T[\.0-9]+$|//|' CVS/Entries

Leatherman

By the way I do not feel that removing the sticky tag is dangerous in concept. It would be better of course via a supported method. But as I said, the resulting state is exactly the same as if the checkins were made to the repository after you had checked out originally, and you hadn't updated yet. If you have local modifications you would be told to merge before you can update. And if you don't have local modifications then you can update cleanly. – Leatherman

Luckily enough I didn't have to work on the legacy CVS project anymore, so I didn't tested this answer, but I will accept this as the accepted answer because it comes closest to what I was looking for. – Rubinstein

The working revision number is at the end lower that the repository one. As a consequence, I cannot commit the "retrieved" version again. The error message: Up-to-date check failed for. Does a solution exists? – Datnow

@OlivierFaucheux If you have local changes that you want to commit, it's the same as if someone else had committed an update. You need to first 'cvs update myfile' which will merge into your working copy any changes in the repository that were committed between your working version and HEAD. You may need to resolve conflicts, but you would then be left with a normal "Locally modified" working file that is at the repository version, and could commit changes normally. – Leatherman

I can't belive there isn't an option to revert to a previous tag non-stickily. In my case, I updated a project to HEAD. But it has bugs. So I want to revert on a few files to a previous tag to make it work. But I don't want to remember there are sticky tags around that won't get updated. I want to be reminded there are pending changes the next time I synchronize my project. – Feral

Answer 2

You can use the -p option to "cvs up" to write to the standard output, which you can redirect to the original file using ">". This avoids stickiness.

Adsorbent

This does work but leaves you with a status of 'Locally Modified'. If you want to update later, you'll need to handle this file specially again. – Leatherman

Answer 3

Or the other way round: Is there any way to update a complete directory to a previous date without setting sticky tags in the first place?

The sticky tag is there to remember that you're not in HEAD. If you commit changes, they won't go there then. And just removing the sticky tag could be dangerous in normal situations.

I think the best way to go is to create a patch from the date the repositories were in sync to an updated copy. Then apply the patch reversed. Create a patch with your modified changes and apply on the other repository.

On a clean (but not synced repo):

$ cvs diff -R -D date_when_synced >patchfile

$ patch -R -pNUM <patchfile

Then in the repo you made the modifications you don't want to lose with cvs up -A:

$ cvs diff -R >patchfile2

Then apply the patch in the "clean" repository:

$ patch -pNUM <patchfile2

I think this could do what you want, if I understood it correctly.

Circumstantial