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.
I am not against having binaries inside CVS, we do that ourselves by much the same reasoning you outline. Here is an additional one: Changes in build environment that happen outside CVS control makes it impossible to recreate an old binary from the sources. Just imagine the problems with registered components in Windows where they change completely unsynchronized with the project files but are used in the current state when the binaries are built! 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? /Bo -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf Of Gerhard Fiedler Sent: den 22 december 2004 13:52 To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: [cvsnt] Re: Purge file history because of user CVS utilisationerror... Bo Berglund wrote: >>That's actually something I really miss in cvsnt: an option to mark a file >>so that the repository keeps only the last version (of all branches) and >>possibly any tagged versions. > > Keeping only the last revision in CVS serves no purpose in a version > control system... If you do this you might as well not store the file > in CVS, because it is equally possible to just keep it on the disk > where you work... I disagree, for these reasons: 1- Keeping these files in the repository gives me a single backup location (the repository). Otherwise, I'd have to run backups of the repository and the sandboxes. 2- Keeping these files in the repository allows me to easily share them with the other developers in a team. Otherwise, I'd have to put them on something like an ftp server and write instructions where to get the missing files and where to place them. 3- Keeping these files in the repository allows me to have a complete project configuration after a checkout. Otherwise, one has to go through the description and collect files from other places and put them in the correct place in the project tree. 4- Keeping these files in the repository makes sure that a commit creates a complete and up to date image of the project in the repository. Otherwise, it is too easy to forget to update that one .ignored file in the (separate) storage that is associated with it. I don't use cvs only as a version control system. I use it also as a project configuration provider, as a centralized backup location and as a team coordination tool. These purposes would be well served with such a feature. I don't see why any of the "otherwise" solutions above would be preferable to having such single version files in the repository. Maybe server load issues, but if the ftp server that would serve them is located on the same machine, this probably becomes a moot point. So far it works fine for me; I just have to manually clean out the not needed revisions for the bigger files. As I imagine that my situation is not unique, and that other people also use cvs for the same purposes (centralized backup, project configuration, teamwork coordination), I thought that this might be a more generally useful feature. At a place I worked, they used to have such files on an ftp server, and the "normal" project files in a version control repository. But everybody liked it when I started to put complete project configurations in the repository; no more jumping between two locations, you get the repository and you know you have "the project" on your disk, in just the right configuration, including all the "one version" files like documentation sent by the client etc. Gerhard _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs