[cvsnt] Re: Purge file history because of user CVS utilisationerror...

Gerhard Fiedler lists at connectionbrazil.com
Thu Dec 23 13:09:35 GMT 2004

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.

Bo Berglund wrote:

> No, what I tried to discuss was the fact that you did not want to allow
> commits to these files in order for them not to grow uncontrollably.
> I think you could achieve this by setting an access control value on
> them that disallows writing. This would keep the file in a normal CVS
> state but unchanging until you modify the ACL and legitimately commit
> and tag a new version of the file. Then change it back to readonly.
> This would save you the problem of pruning the file by not letting it grow
> while still having it under version control.
> Maybe?

Yes, for some cases that's an option, but not always. In one case we
regularly got a pretty large file from a client, which was versioned at the
client, so there was no need to keep gigabytes of version history on our
side. (And there was no use going back on the whole file anyway.) But we
had to have it in our project tree. So we manually got rid of the history
on every commit. 

Maybe these cases are not all that common, and maybe a general repository
cleanup script can help here also. I just thought I'd test the waters; you
never know, an outcry of the general user base could have made this a top
priority :)


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