Scott Palmer <scott.palmer@2connected.org> writes:
> If Subversion is going to throw away metadata that most other file
> operations (most copy, ftp, http file transfers for example)
> preserve, e.g. mod times, then the onus is on it to justify that.
> So far the answer I always hear is, "always use subversion to track
> file versions"... to which I'm not sympathetic. :-)
>
> I have no desire or ability to force everyone and everything I
> exchange data with to use Subversion exclusively. Mod times would
> work fine for tracking file versions, if tools like Subversion didn't
> break them (and insist they were useless in the first place because
> some other tool might break them as well).
>
> There are plenty of existing tools and/or scripts out there that do
> their work based on time stamps. Subversion itself argues that
> 'make' only works properly if the time stamps are just so. It is the
> reason often quoted for NOT tracking the file mod times... and yet it
> seems the developers ignore the fact that other tools use time stamps
> in similar ways and work best when the mod time is accurately tracked.
>
> Why should everyone change their workflow to accommodate the fact
> that subversion doesn't save meta-data? That "whole bunch of
> scripts" may be difficult or impossible to change. Filesystems keep
> track of mod times for a reason. Why does subversion assume that
> reason goes away completely with a VCS in place? The OS' filesystem
> is still there! You don't assume 'make' is integrated with
> Subversion, why assume everything else must be?
There's a certain attitude that comes up too frequently, when people
propose features and the Subversion committers don't react with
sufficient enthusiasm :-). Here that thought was expressed in
"it seems the developers ignore the fact that other tools use time stamps"
We don't "ignore" much around here. What we do is make cost/benefit
analyses. We try to determine the cost of of a feature (including
implementation, maintenance of the code forever after, documentation,
and fielding future user questions about edge cases) and compare that
to the benefits (a new ability in Subversion, no longer having to
field user questions about the feature's lack, etc).
Sometimes we decide the benefit isn't worth the cost. Such
determinations are always subject to future re-evaluation, of course.
Maybe someone will point out a benefit no one had thought of before,
or propose a clever implementation that reduces the cost. Conclusions
are always tentative, in the sense that they're not meant to close off
further discussion.
So I'm not complaining about the substantive content of your mail.
However, I and the other developers do not appreciate inaccurate
accusations that we are "ignoring" arguments when we are instead
acknowledging those arguments, engaging them critically, and weighing
them against counterarguments. I believe several developers have done
so in this thread (or in previous threads on the same topic, if not in
this exact thread). Just because they didn't come to the conclusion
you wanted doesn't mean they ignored the arguments in favor of that
conclusion! :-)
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 11 20:59:07 2005