At 12:20 AM 5/14/2004, you wrote:
>No, Subversion is exactly just version control. I never understand
>what's wrong with putting the unversioned data on network filesystem.
Heh, you must be one of those "relatively small projects" guys
I was alluding to. ;-)
Seriously though, suppose some of your GUI windows rely on lots
of bitmap images, and that your math code depends on source files
containing huge lookup tables generated by various tools that
are complex to setup. It's very desirable to have this stuff
included automatically during a checkout. Although nobody cares
about "revision histories" for these files, they do present very
similar version control problems as ordinary source code.
You will no doubt propose that we simply copy these files to an FTP
server and instruct the team to periodically download the data files
to their source code directory, or maybe use rdist or somesuch. But
have you ever worked on a project with hundreds of data files being
edited by different people? It's a huge mess, because people are
always overwriting each others' files, forgetting to delete deadwood,
etc. Since these files are already in the source code directory tree
(and many of them are in fact source code), it actually seems quite
strange to ask that they be managed by a separate 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.
Correct -- this is exactly like implementing "rm -Rf *" and then
arguing that the ability to delete individual files would be
"overkill". :-D
Once again, you need to think from the perspective of BIG projects,
where a single file's history might have thousands of revisions.
Think about that... a file history window with a THOUSAND entries.
This is exactly the case where complicated global dump/filter
operations are completely infeasible, and simply regenerating a
new repository with no history would be too extreme. Subversion's
job is to manage revisions, and I see nothing outlandish about
people asking for the ability to manage revisions that occurred
in the past.
I want to write a check-in hook that deletes the histories
of .bmp files except for their most recent 3 revisions. Is
that crazy? This seems like exactly the kind of problem that
version control models are supposed to facilitate.
Cheers,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 10:31:11 2004