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

Florent Gilain florent.gilain at direct-energie.com
Wed Dec 22 14:37:49 GMT 2004


Hummm..My original question seems to be hard discussed here  ;-))

Finally, my goal was just to be able to select 1 file and to ask CVS to
delete history of this file only... 

Florent

-----Message d'origine-----
De : cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] De la part de
Bo Berglund
Envoyé : mercredi 22 décembre 2004 14:56
À : Gerhard Fiedler; cvsnt at cvsnt.org
Objet : RE: [cvsnt] Re: Purge file history because of user
CVSutilisationerror...

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




More information about the cvsnt mailing list