Efficient way of cvs committing with cvs update if needed?

Question

Firstly, where I work we're forced to use CVS and don't have any other choice. I personally use git.

Sometimes I don't always do a cvs update on a module but I'll download the actual file off the production server which is guaranteed to be the latest ( 99% of cases ).

I end up doing a cvs commit to find I failed to update so the scenario is like this:

cvs commit file.xml
cvs commit: Up-to-date check failed for 'file.xml'
mv file.xml 2
cvs update file.xml
rm file.xml
cvs mv 2 file.xml

I was thinking about writing a shell script that automatically cvs updates the files I'm committing and commits over them... but wondering if there's some native way of doing it.

Any advice other than not using cvs appreciated!

PS - And I use !!:n where n is the number. I just didn't use that in my code example since it's more legible as it is.

Answer 1

Use CVS as it was intended to be used. In other words, cvs update before cvs commit. cvs update modifies some of the other information in a CVS sandbox, which simply copying the file won't do.

You really shouldn't have direct access to the repository anyway. That allows a lot of potential problems.

Answer 2

I am suspecting that the download of the file is an optimization step? The reason that an update is a required step prior to committing is to keep the context of your file in lockstep with that on the server. I can think of several problems with the manual method:

1. The manual download may be faster, but it also potentially overlooks related file changes.
2. The problem you describe: you must update anyway to get CVS to accept your check-in.
3. Assuming you do manage to work around it, I suspect that you will be bitten by subtle CVS bugs anyway.

If your work needs to be in isolation, make a branch and work there. Jiggering the CVS manually is a road to tears.

Answer 3

What you're doing in that sample session is actually pretty rude behaviour towards the author(s) of the more recent revision(s) that were apparently committed in the meantime as you will effectively revert all of those changes. That's precisely why CVS requires files to be based on tip revisions (aka "be up-to-date") before allowing them to be committed.

However, if reverting or replacing those intermediate changes is exactly what you want to do then the steps you quote are indeed very possibly the quickest way to do so. The downside of that approach though is that the reversion process is not tracked: At least on CVSNT doing a proper reversion would result in the recording of mergepoints so that a revision graph would show which revision you reverted to.

Not moving the file away before the update would at least merge the remote changes with your local changes. This should however never be committed without verification so a fully scripted approach to this scenario would make no sense whatsoever.