kfogel@collab.net wrote:
> Scott Palmer <scott.palmer@2connected.org> writes:
> ...
>>In any case, I thought I had read on the list of a patch that has
>>already been made available. So the cost appears relatively low. If
>>the development team considers this a low priority (and I agree that
>>it is), it appears that the cost is in proper proportion to the
>>benefits.
>
>
> That's how I'd sum things up too. Note that the real cost is the cost
> of evaluating that patch and the design behind it, which (so far) has
> looked pretty high. The mere existence of the patch doesn't change
> that cost.
Is there any way to reduce these costs, I mean could I do something
about it?
What is meant by "evaluating that patch and the design behind it",
can you describe what is usually done (in a few sentences, it shouldn't
cost you a lot of time) or give a link to that information?
Reasons why I want to have it:
- Tar files store it. I want to be able to give some stuff to someone
else in the form of a tar file. If I want to give him/her a new
version, taken from a freshly checked out WC, then all timestamps
are different from the old version, even though there are changes
in a few files only (this could be solved using --use-commit-times,
maybe, at least to some extend).
- 'make' uses them. If the right order is preserved, this could also
be solved using --use-commit-times, but right now I believe that
the right order is not preserved.
- These informations are stored and presented by every unix/linux
filesystem. Not storing them renders this part of the filesystem
useless. Why did the developers of the filesystems take the effort
to implement it? Because there is some use to it, whatever it may
be, perhaps something I never thought of.
- People, including me, want to know "when was the last change to
that file?", even if the file was laying around for some time
(months/years!) before being put under subversion control. This
problem cannot be solved using --use-commit-times.
In general, when putting something under a VCS, I want to loose
*as little information as possible*.
Since Oliver's problem is the nonexistence of a windows build of
subversion with the meta-data patches, there might be a solution:
Branko, could we somehow convince you to build a windows build of
the meta-data version, after the problem with zlib got sorted out?
Please? :)
Have fun
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 12 11:36:19 2005