Concerning Re: Subversion Problem - How to sav
Ryan Schmidt wrote on 11 Jul 2008, 2:37, at least in part:
> On Jul 10, 2008, at 21:43, Ben Collins-Sussman wrote:
>
> > This feature has been discussed over and over through the years; if
> > you search the dev@ archives, you can read the debates. The opinion
> > of the dev team is that this is not a useful feature in general;
> > while it might help a very small minority of users that wish to
> > track original timestamps, it would create more trouble and
> > complexity for the majority, and be hard to maintain. So the lack
> > of this feature is a deliberate decision, not an accidental
> > oversight.
> >
> > The arguments against the feature have basically been:
>
>
> Hi Ben. I'll repeat some arguments that have been made over and over
> for this feature:
>
>
> > * When no version control is used, then it's clear file timestamps
> > are critical. They're the only indication of a file's "version".
> > But once the files are placed into version control, what's the point
> > of tracking the original datestamps? Version control is now
> > providing much more detailed tracking of versions and dates. It's
> > solving the problem is a much more thorough way.
>
> When importing an existing project, I consider it important to know
> when those files were last modified. I may be importing the project
> today, but maybe I developed over a period of months last year. I'd
> like that metadata preserved.
Even more so as quite a many of those "old" files may not be
modified again any time soon, while the original last modified
stamp frequently allows for a very quick guess in what context the
file was created/modified.
It may sound weird to code developers, but if for instance I put all
my digital photos or scans into a repository the destruction of the
lastmodified stamp deprives me of very valuable first sight
information:
a) when the photo was taken (I would have to open the photo and
check for internal metadata - if there is any)
b) or at which time the photo was last edited, providing me with a
good clue to which camera or photo editor was used a/o which
degree of quality both the original photo and my photo editing
abilities had. IOW if the photo is up to my current standard or
should be worked on or is as good as the original hardware allowed
for and probably should be retaken if possible.
> It's not Subversion's place to decide that the modification time of a
> file is not important. It is important to me, and to many other
> Subversion users as well.
Well said, Ryan. The days when software (developers) decided
what the user could do or should need are definitely over. Or so I
would think. Even MS understands this in significantly growing
degrees.
To give it another angle: back in the early 90s I tried a lot of
shareware programs, word processors, databases, stuff like that.
The general experience was that German software would strictly
limit capabilities to what the programmer thought right and
sufficient, while American software carried the idea of giving the
user the greatest choice to make it fit to his needs. I considered
this a deeply rooted cultural difference. And there was and is no
doubt about which I prefer: the address database which allows me
to set up fields as I need or the one that gives me five fields of 15
chars and a hardcoded list for Herr/Frau/Firma. Both written in
Clipper BTW.
> > * Version control is typically used for code.
While typically software developers will apply version control the
above statement contradicts the basic idea of SVN treating
anything just as data, ASCII, binary, no matter. That's stated in
the "Book" and in many postings on these lists. Like the idea of
using SVN less for "versions" but as a convenient undo tool for
the single developer or to ease co-operation in teams.
> > Having timestamps
> > touched by 'svn update' solves the 90% use-case of causing programs
> > like 'make' to rebuild exactly what has changed. This is a useful
> > and important default behavior.
>
> Not all code uses make. I don't write compiled software; I write
> interpreted scripts in languages like php and bash. Others might be
> writing in ruby or python or perl. We do not need makefiles and we do
> not need to be bound to the deficiencies of make.
>
> Also, not all repositories contain code. I have a second repository
> for musical compositions, for example.
>
>
> > * For all other cases, the 'use-commit-times=true' option causes
> > timestamps to reflect repository mod-times, rather than 'svn up'
> > mod-times, thus providing the same sort of simulated
> > versioning-via-timestamp for files being exported to people without
> > subversion.
>
> "use-commit-times=true" is sufficient for my purposes, after the
> initial import of an old project. But for old projects, as mentioned
> above, import time is often not even close to modification time.
>
> Also the case has been made that for applications like web site
> development, it's important for caching reasons to have the same
> modification time on a file (whether that be the original
> modification time or the commit time is not important). If you check
> out a working copy today and serve it via a web server, it sends out
> the (static) files' modification times. If you then check out a new
> working copy tomorrow, or use svn switch or something, the
> modification time on the files changes, even though the file is the
> same. The web server will think the file has changed and will send
> out the new modification time which will cause browsers to
> unnecessarily redownload the files, wasting time and bandwidth. So
> for web site applications, at least at the server side, the default
> of "use-commit-times=false" could be considered harmful.
In addition it forces the user to use some specific tool to
synchronize production websites with local working copies when
this either may not be convenient for the user and the
specific environment or not possible at all (e.g. hosted website with
limitations as to running SVN or rsync on the server).
Jan Hendrik
---------------------------------------
Freedom quote:
A room without books is a body without a soul.
-- Marcus Tullius Cicero
---------------------------------------------------------------------
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-11 12:26:50 CEST