John Peacock wrote:
> There isn't 'active resistence' but rather 'conservative caution'.
> There has not, to date, been a design proffered which preserves
> something like mtime without serious side effects. For example, because
> mtime is based on the client machine (as opposed to commit time, which
> is based on the server), if the client machines are not synchronized,
> the value is not meaningful. At the very least, mtime is much more
> prone to inconsistency among multiple machines because of this.
> Additionally, *everyone* who uses Subversion with a build tool like
> make, Ant, etc. will have their build process break completely if this
> feature gets turned on (even by accident).
>
> If you or someone else who believes this is a vital feature can produce
> a design that would deal with these issues, even if you cannot code it
> yourself, I have no question that the feature will get added. But that
> hasn't happened yet, and until that happens, claims that the project is
> resisting this are just paranoia. In all of my years in the open source
> community, I can assure you that this is one of the most careful and
> considered projects I have ever seen. Every single feature is carefully
> considered before being added, and as such the project is extremely
> stable and consistent.
The one place I can see value to this is a directory where users have been
copying a file as file.c.1 file.c.2 file.c.3, etc... I have had one case
like this, and as I did not have anything else available I used RCS to save
the different revisions. When I checked the log, I was pleasantly surprised
to see that RCS had used the name of the file owners and mtime as the check
in date rather than my name and the date of the day.
I can see the drawbacks, they did not really check those file in (I did !),
but it would be nice to have as an option, and definitely would need special
privileges to prevent people from impersonating others.
--
Yves.
http://www.SollerS.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-15 21:57:48 CEST