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 :) Gerhard