> >Nope. I need the same thing, and the only solution I've found is to use
> >CVS for the data tree and SVN for the source tree, which is a pain (but
> >better than using CVS for everything).
> >
> Are you saying that CVS handles changing binaries better than SVN?
> What's your definition of "better"?
CVS and RCS allow you to delete (out-date) old revisions,
whether binary or not. If you are short of space, this
helps.
> This comparison is tricky, because there are two kinds of "unlink" in
> Subversion: "svn remove", which we have, and "svn obliterate", which is
> on the wishlist. The latter would remove all traces of a file, its data
> and history, from the repository.
How about "svn delete.
where remove <= delete <= obliterate.
svn remove removes something from the HEAD, but
leaves its versions and log entries in the
repository.
svn obliterate, as you describe it, removes
all traces of a file, it's data and history,
from the repository.
Q: who wants svn obliterate?
I suppose that svn obliterate might be needed for some
legal requirements, e.g. where you have been working for
the CIA, and now no longer are allowed to have the
source file, nor even to mention that it existed.
Myself, I would prefer something not quite so extreme:
svn delete. Remove the data, the revisions, for a file,
but leave the log messages - noting that the revision once
existed, but now no longer does. I don't work for the CIA,
although the comp;anies that I have worked for - Gould,
Motorola, Intel, and AMD - are quite insistent that I not
keep any coe that I wrote while working for them.
> I _still_ don't see a valid reason why those can't be just ordinary
> files sitting on the filesystem.
The original posters were talking about binary files:
me, I am talking about ordinary source code.
E.g. I have been maintaining several tools and libraries
since my undergraduate days, 18+ years ago. E.g.: debug.h,
a debug header; mkIrecog, a decoder generator; getnumber,
a number parser that recognzes numbers such as 1M-1;
libuarch, a CPU microarchitectre library;
and PerlSQL. Various of these have been placed into the
public domain; but sometimes, when I have started using
them at companies, the company has owned the rights to
the changes. E.g. mkIrecog was the basis for the Intel
P6 instruction decoder; I own the rights prior to Intel,
and I own the rights sbsequent to my leaving Intel; but
do not own the changes that I made while I was at Intel.
I tend to keep all of my code in a repository, that has
changed over the years from SCCS to RCS to CVS and may soon
change to Subversion. I try to keep company owned stuff
separate, but nevertheless, every time I have left a company
I have had to go and RCS out-date some revisions that sneaked
into my personal repository. (Bug fixes and portability
tweaks to existing code I check into my repository;
new features added on behalf of my employer they own.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 17 18:50:17 2004