[cvsnt] Re: Cleaning "fake" revisions from repository

Oliver Giesen ogware at gmx.net
Sat Aug 6 13:11:43 BST 2005

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.

Danail Manolov wrote:

> > > 2. Is there a way for me to clean my repository from those "fake"
> > > revisions that just add noise and no useful version information?
> > 
> > There is an admin command that will do this, but why bother??
> Because history of a lot of files is now full with fake revisions.

Well, why did you commit them in the first place? Regardless of the bug
you identified (and which has been fixed as you also already found
out), personally I think that not a single file should be committed
without first verifying the changes within - *especially* when there's
a lot of them. I would *never* commit at the directory level. IDEs tend
to do a lot of touching files and putting useless auto-generated stuff
such as history lists into project configuration files and such, all of
which does not belong into the repository IMO (often these changes
contain references to local paths and such that would be invalid on
another developer's machine).

What I typically do when committing a large number of files is this
(using WinCvs):
1. Close all IDEs and editors that might potentially still have files
2. Filter by committable files and turn on flat view (i.e. see all
committable files in the entire folder hierarchy).
3. Select all and run Status on them. That usually resets the modified
state on those files where only the timestamp has changed.
4. Select groups of files I suspect of belonging to the same change
(ideally of course you should commit after every change so this should
often be equivalent to selecting all - but then of course reality
seldom is that perfect).
5. Invoke the commit dialog and from there invoke the external Diff
tool for every single file in the selection to preview the changes that
will be committed to the repository. While doing so I compose the log
message (having a two-monitor setup helps a lot here). Upon discovering
IDE-made unwanted changes, I correct them, fire up the IDE, verify that
everything still works and start again from tep 3.
6. Once all identified changes are documented in the log message I
confirm the commit and continue with the next set of changed files
until all files are committed with a meaningfull log message.

> So what is the admin command and can it fix all files at once?

The command is cvs admin -o. It allows you to delete arbitrary
revisions from the repository. Which revisions to delete you have to
determine yourself, so no it could not automagically fix all files at
once. I don't know whether Tortoise does have a UI for this. In WinCvs
you could access this command via the Graph View (i.e. the visualized
revision history) by using the context menu.

> > > I found the source of the problem, and it is in CVSNT v2.0.62.1817
> > > that comes with TortoiseCVS.
> > 
> > That is a very old version of CVSNT and should not be used!
> Yes, but I'm not sure if newer versions of CVSNT will integrate well
> with TortoiseCVS, and TortoiseCVS is really too enjoyable version
> control to be rejected...

So, I think your real question should have been whether anyone has any
negative experiences with running TortoiseCVS with a later version of
CVSNT, no? Preferably asked on the Tortoise list/group/forum/whatever.

As Tortoise only uses the client part of CVSNT (which is, as Tony often
puts it, really dumb) I think there is very little risk that anything
goes severely wrong.
Just like WinCvs, Tortoise is invoking CVSNT using the CVSGUI protocol
IIRC. WinCvs is working fine with the latest version of CVSNT so I
really don't see why Tortoise shouldn't.

> > > Latest CVSNT (ver. also has correct behavior.
> > 
> > Exactly, and that is why you should not use the old version.
> Yes, but latest CVSNT versions is compiled in different way and need a
> lot more libraries than version that comes with TCVS. And see above -
> I'm not sure if I will have other problems with them...

Are you compiling CVSNT yourself? Otherwise what does it matter to you
what libraries it uses? The installer takes care of that completely.
There are no external dependencies at all that you need to bother about
if you just use the installer.


----  ------------------
JID:  ogiesen at jabber.org
ICQ:  18777742     (http://wwp.icq.com/18777742)

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook