[EMAIL PROTECTED] (Larry Jones) writes:
> Jorge Godoy writes:
> >
> > There would be very nice if CVS had an option that made him remove the
> > non-pertinent repository files. Files that were removed and still
> > exist in a checked out copy are useless and just give warnings on the
> > client side. If CVS was able to delete these files it would be
> > possible to have less scripting around it and have a portable
> > solution. Files that CVS doesn't know nothing about should still
> > remain...
>
> I'm sorry, I can't understand what you're trying to say. Could you give
> an example of what you mean?
Do you know rsync?
With it you can sync two machines. If a file is removed in one (lets
call it sever) it's also removed on the other (lets call it client).
I want something like that: I have an obsolete file, I "cvs rm" it and
commit my changes. When my development partner makes a "cvs up
-newflag" the file will be automatically removed from his machine.
Today CVS only gives me a warning telling that the "file no longer
belongs to the repository".
On CVS, our server would know if the file still exists or was removed
and would reflect that operation on the client, just like rsync does.
I could do that with some scripts, but these won't be as portable and
won't benefit from all the checks that CVS does and wouldn't run on
every platform that CVS runs...
The confuse part may be the one where I talk about "unknown
files". These are the ones that CVS marks with a question mark. With
these, CVS should do nothing (they are usually output from some code
processing).
Is it clearer now?
Thanks!
--
Godoy. <[EMAIL PROTECTED]>
Departamento de Publica��es
Publishing Department Conectiva S.A.
