Pete Gonzalez wrote:
> 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. ;-)
Oh be serious. Is 100 developers and 7Mloc small? Yes I've worked on
such a project, and we did keep our unversioned bits on a well-known
network share.
> 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.
All right, providing *integrated* exclusive access to unversioned files
is the best argument to date. Of course, Subversion hasn't a chance of
doing this until it supports exclusive locks -- my pet project for 1.1 :-)
>>> 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.
>
> There also seems to be a strong (and valid) design concept of "never lose
>
> Correct -- this is exactly like implementing "rm -Rf *" and then
> arguing that the ability to delete individual files would be
> "overkill". :-D
Oh I'm sure "svn obliterate" will accept the -r to restrict the range of
revisions, if that's what you mean.
> 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 agree. Like I said, the functionality is on the wishlist, but it
probablu won't happen soon. I'd be pleasantly surprised if it will
happen during the 1.x cycle.
> 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?
It's...interesting. But I see your point.
> This seems like exactly the kind of problem that
> version control models are supposed to facilitate.
Yup. I'll just note that we've now moved away from the "unversioned" to
the "versioned in a limited number of instances" world, and this is
_way_ more complicated.
What I'd like to see is discussion about how unversioned files behave
wrt branching and merging, for example; the edge cases are interesting/
-- 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 12:39:53 2004