Glenn Maynard wrote:
>On Thu, May 13, 2004 at 10:26:47PM -0700, Pete Gonzalez wrote:
>
>
>>Does Subversion have something like this? If not, it seems like
>>it would be pretty trivial to implement, since it basically
>>involves subtracting existing functionality rather than implementing
>>something new. :-)
>>
>>
>
>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"?
>The general response to this seems to be "why are you putting data in
>version control if you don't want it versioned"; the answer is that svn
>isn't just version control--it's a respository.
>
>
No, Subversion is exactly just version control. I never understand
what's wrong with putting the unversioned data on network filesystem.
>There also seems to be a strong (and valid) design concept of "never lose
>data", but removing data is not losing data. My filesystem doesn't lose
>data, but that doesn't mean it doesn't support unlink().
>
>
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.
>I don't think it would be trivial, though--nothing useful is ever trivial.
>For example, the protocol is based on sending diffs--if old revisions
>aren't kept, the server can't produce diffs, since it doesn't have the
>client's old revision.
>
>
How do you suppose Subversion does the initial checkout? :-)
>>A related feature would be the ability to delete old revisions.
>>For example, we have some relatively ancient revision histories
>>in our repository, and it would be nice to issue a command such
>>as "Collapse all changes between Jun 1, 2003 and Jan 1, 2004
>>into a single revision." This would not only reduce the database
>>
>>
>
>This was my original question; I think being able to say "keep only the
>latest copy, don't version" is more useful and require less babysitting,
>though.
>
>
I _still_ don't see a valid reason why those can't be just ordinary
files sitting on the filesystem.
>>footprint, it could also dramatically reduce the amount of time
>>you have to wait for operations such as the revision history
>>window in TortoiseSVN. (I realize that it might be possible to
>>accomplish this with a 200-step manual procedure involving
>>"svnadmin dump," but maybe it could be automated?)
>>
>>
>
>The "dump" procedure has problems: it requires taking the repository
>down, takes a long time, and requires that you have enough space to
>store at least one extra copy of the repository (and if you're doing
>this to free up space, you probably don't). I think you can only delete
>entire ranges of revisions this way, too, not revisions for specific
>files, at least without doing special dump filtering.
>
Which is why we have svndumpfilter.
> Also, it has the
>update problem: clients that have revisions that you deleted won't
>be able to update cleanly.
>
>I think there's an issue open for implementing a simpler way to wipe out
>revisions, but if I remember correctly, it's expected to still have most
>of the above problems.
>
>
Yup. And others.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 09:22:56 2004