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

[Bo Berglund]

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
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
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt