You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Norbert Unterberg <nu...@gmail.com> on 2008/07/10 21:06:47 UTC
Re: Subversion Problem - How to save file modify time?
2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> Dear Invendor,
>
> This is a software company in china. I'm an engineer at
> develope-management department.
>
> We used other version control system as perforce or starteam before.
> Now we are trying subversion.
>
> During trying subversion, we find that file modify time could not be
> saved into subversion and get from subversion.
>
> Is it a design problem or deploy problem ? I hope it's a deploy
> problem. How to shot it, if a deploy problem.
>
There is a configuration option "use-commit-times" which you can find
in the documentation, It does not preserve the real file modify time
but the commit time which might be good enough.
However, for software development, the default behaviour (file time is
the time of last update or checkout) usually works best.
The problem with preserving file modify time is that it is very hard
to do right. What is the correct modify time if two people change the
same file and then they commit/update/merge the data? What to do when
merging a branch? IF SVN modifies the file contents during a commit
(see svn:keyword property) does that count as a file modification or
not?
Norbert
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Subversion Problem - How to sav
Anders J. Munch wrote on 11 Jul 2008, 10:25, at least in part:
> sussman@gmail.com 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, [...]
>
> I sincerely doubt it's any sort of minority, let alone a very small
> one.
The frequency this comes up on the list - with the notorious
supporters only falling in again and again - should prove the small
minority myth.
Jan Hendrik
---------------------------------------
Freedom quote:
The only justifiable purpose of political institutions
is to assure the unhindered development of the individual.
-- Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Subversion Problem - How to sav
Erik Huelsmann wrote on 11 Jul 2008, 13:38, at least in part:
> Well, it *is* subversion's place to decide which features to support
> and which ones not. It also *is* Subversions obligation to provide you
> with a stable platform which you can depend on. Implementing the
> strictly necessary features is one of the ways of limiting chances at
> instability.
Admitted, and I don't deny the core developers to decide what to
implement or not, they even may decide to turn SVN into a
musicbox or a submarine for that matter, and I certainly don't want
to open the can of arguments once more, but what I don't get is
Why last modified time is harmful, but commit time not. Other
networked implementations rely on the use of a specified
timeserver as well, so running computer clocks should not be an
issue.
> If you want tools which have all the features - but get none of them
> exactly right - you can always buy MS software.
For the time being I can do with the workarounds and from time to
time when a reasonable workflow requires it I deliberately break
these workarounds, risking data loss.
At this moment I am not actively testing alternatives, so it might
happen that either the things I find wanting will be implemented
sometime or my need for them goes away by a different
environment (or both as these kind of things are). But I keep an
eye on developments by competitors. Just as I do with Linux:
when finding there finally are true competitors for the chief
applications I use running under Linux I will switch to Linux. Like a
HTML editor that matches Homesite or a word processor or image
editor which don't define themselves for about 50% by JUST NOT
BEING LIKE THE MS/ADOBE PRODUCT. That's not a value of its
own and I gladly state that this is not a notion of Subversion folks.
> If you think Subversion is missing functionality, you can always write
> your own client: Subversion is just a set of libraries; the actual
> code in the SVN client is extremely limited. You could even write your
> own client in another language than C: we have language bindings for
> Java, Python, Perl, Ruby and Scheme and are willing to accept others.
Thanks for reminding me I have no degree from RWTH Aachen!
<G> Seriously I have neither the knowledge nor the time to do that.
Have a fine day!
Jan Hendrik
---------------------------------------
Freedom quote:
Many of our fellow citizens no longer have the tolerant souls
and morals of free men and women.
They have the souls and morals of busybodies
and petty tyrants who want to run their neighbors' lives.
-- Edward L. Hudgins
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: using other diff's (again)
Posted by Jan Hendrik <li...@gmail.com>.
Concerning using other diff's (again)
Michael Maxwell wrote on 11 Jul 2008, 12:39, at least in part:
> From the recent discussion on saving the file modify time:
> I think this is called "software freedom", and I just want to say that
> I feel the same way about using a non-subversion diff, or a format
> other than the 'unified' format for the diff outputs.
>
> So I'm hoping that my request (and that of others) to allow *both* the
> particular diff program *and* any command-line parameters to be
> specified in the ~/.subversion/config file not get left off the to-do
> list. At present, the config file only allows an alternative diff
> program to be specified; it does not allow command-line parameters to
> be given (those have to be passed on the command line every time you
> run 'svn diff', or else you have to write a wrapper script with clumsy
> references to numbered parameters). And there is no way (short of a
> wrapper) to turn off the -u parameter.
Mike,
from the "~/.subversion/config" I gather you work on some *nix OS,
so this won't help you. However, in TortoiseSVN (for Windows) one
can specify parameters for alternative diff/merge tools in the
settings. I did this to use WinMerge with parameters different from
the default suggestion. And yes, doing this in Subversion conf
would simplify this for use of different clients in parallel.
Jan Hendrik
---------------------------------------
Freedom quote:
Freedom is not created by government
nor is it a gift from those in political power.
It is, in fact, secured more than anything else
by limitations placed on those in government.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
using other diff's (again)
Posted by Michael Maxwell <mm...@casl.umd.edu>.
Re: Subversion Problem - How to save file modify time?
Posted by Erik Huelsmann <eh...@gmail.com>.
> > 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.
Well, it *is* subversion's place to decide which features to support
and which ones not. It also *is* Subversions obligation to provide you
with a stable platform which you can depend on. Implementing the
strictly necessary features is one of the ways of limiting chances at
instability.
If you want tools which have all the features - but get none of them
exactly right - you can always buy MS software.
If you think Subversion is missing functionality, you can always write
your own client: Subversion is just a set of libraries; the actual
code in the SVN client is extremely limited. You could even write your
own client in another language than C: we have language bindings for
Java, Python, Perl, Ruby and Scheme and are willing to accept others.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Subversion Problem - How to sav
Julian Foad wrote on 11 Jul 2008, 9:45, at least in part:
> This is a pretty well written answer to a Frequently Asked Question
> that doesn't seem to be in <faq.html>. Fancy putting it there?
Without the counter arguments it could be reduced to one single
line:
This is not and will never be possible by design( and generally
considered an insane idea*).
Along with quite a number of others I have argued repeatedly for
preserving this timestamp in the past. I am still with SVN as the
limitations of other systems were more harming to the environment
and workflow here. Besides there is old saying: Don't look a gift
horse in the mouth.
* "All people who behave strangely are not insane ..." (Bringing Up
Baby, 1938)
Jan Hendrik
---------------------------------------
Freedom quote:
Freedom of religion, freedom of the press, and freedom of person
under the protection of the habeus corpus, these are principles
that have guided our steps through an age of revolution and reformation.
-- Thomas Jefferson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Subversion Problem - How to sav
Anders J. Munch wrote on 11 Jul 2008, 10:25, at least in part:
> sussman@gmail.com 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, [...]
>
> I sincerely doubt it's any sort of minority, let alone a very small
> one.
The frequency this comes up on the list - with the notorious
supporters only falling in again and again - should prove the small
minority myth.
Jan Hendrik
---------------------------------------
Freedom quote:
The only justifiable purpose of political institutions
is to assure the unhindered development of the individual.
-- Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
I wrote:
>
> Secondly, even with timestamp-preservation enabled, we can still give
> make some help. The thing is, the problem only occurs when files are
> backdated.
On reflection, that's not true. Even if source files are
forward-dated, as long as they're older than the object files, make
will be fooled.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
I wrote:
>
> Secondly, even with timestamp-preservation enabled, we can still give
> make some help. The thing is, the problem only occurs when files are
> backdated.
On reflection, that's not true. Even if source files are
forward-dated, as long as they're older than the object files, make
will be fooled.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Ben Collins-Sussman wrote:
> I wrote:
> >
> > The "make argument" is flawed. Read my 2008-06-10 posting
> >
> http://article.gmane.org/gmane.comp.version-control.subversion
> .user/77803
>
> Interesting! I agree that 'make' is old and lame. But given that
> it's still ubiquitous: what's the harm in supporting it?
None. But there are at least two things that can be done about that.
The first is the obvious one: make timestamp-preservation optional.
Secondly, even with timestamp-preservation enabled, we can still give
make some help. The thing is, the problem only occurs when files are
backdated. Which means it should be detectable: Whenever an update
caused a file timestamp to go back in time, Subversion could warn the
user that a clean build might be required. At least the GUI clients
could do that; I don't know how well the concept of a warning fits
with the command-line client.
regards, Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Ben Collins-Sussman wrote:
> I wrote:
> >
> > The "make argument" is flawed. Read my 2008-06-10 posting
> >
> http://article.gmane.org/gmane.comp.version-control.subversion
> .user/77803
>
> Interesting! I agree that 'make' is old and lame. But given that
> it's still ubiquitous: what's the harm in supporting it?
None. But there are at least two things that can be done about that.
The first is the obvious one: make timestamp-preservation optional.
Secondly, even with timestamp-preservation enabled, we can still give
make some help. The thing is, the problem only occurs when files are
backdated. Which means it should be detectable: Whenever an update
caused a file timestamp to go back in time, Subversion could warn the
user that a clean build might be required. At least the GUI clients
could do that; I don't know how well the concept of a warning fits
with the command-line client.
regards, Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, Jul 11, 2008 at 3:25 AM, Anders J. Munch <aj...@flonidan.dk> wrote:
>> * Version control is typically used for code. 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.
>
> The "make argument" is flawed. Read my 2008-06-10 posting
> http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
Interesting! I agree that 'make' is old and lame. But given that
it's still ubiquitous: what's the harm in supporting it?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, Jul 11, 2008 at 3:25 AM, Anders J. Munch <aj...@flonidan.dk> wrote:
>> * Version control is typically used for code. 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.
>
> The "make argument" is flawed. Read my 2008-06-10 posting
> http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
Interesting! I agree that 'make' is old and lame. But given that
it's still ubiquitous: what's the harm in supporting it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On Jul 15, 2008, at 17:42, Karl Fogel wrote:
> "Ph. Marek" <ph...@bmlv.gv.at> writes:
>> On Dienstag, 15. Juli 2008, Karl Fogel wrote:
>>> You might have the wrong impression about how this group works...
>> ...
>>> Eventually, someone will probably do it. But that will happen
>>> when it's
>>> important enough to a programmer to implement it, or important
>>> enough to
>>> some company to pay a programmer to do it. That's how things
>>> happen here.
>> Or, possibly, has already done that:
>> http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
>> owner-group-mode/
>> text-time/
>>
>> If that's updated to work against trunk it could suffice ...
>> (Or, IMO, maybe it's easier to take the changes on this branch and
>> try to get
>> them to work on trunk.)
>
> Yes, sorry, I should have pointed that out. Ph. Marek has already
> worked on this, but no maintainer has had time to evaluate the
> patches.
> They're all above in the public repository, though. You can also do
>
> svn log --stop-on-copy \
> http://svn.collab.net/repos/svn/branches/meta-data-versioning/
>
> to see an overview, and you can get the diffs in the obvious way too.
>
> Now you know everything we know :-).
>
> -Karl
Ah, this is interesting. I'll have a look at that when I have a
working internet connection again (tomorrow at work). I'd like to see
how this branch deals with (or side-steps) the issues I raised in my
other mail.
// Ben (bpsm)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"Ph. Marek" <ph...@bmlv.gv.at> writes:
> On Dienstag, 15. Juli 2008, Karl Fogel wrote:
>> You might have the wrong impression about how this group works...
> ...
>> Eventually, someone will probably do it. But that will happen when it's
>> important enough to a programmer to implement it, or important enough to
>> some company to pay a programmer to do it. That's how things happen here.
> Or, possibly, has already done that:
> http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
> owner-group-mode/
> text-time/
>
> If that's updated to work against trunk it could suffice ...
> (Or, IMO, maybe it's easier to take the changes on this branch and try to get
> them to work on trunk.)
Yes, sorry, I should have pointed that out. Ph. Marek has already
worked on this, but no maintainer has had time to evaluate the patches.
They're all above in the public repository, though. You can also do
svn log --stop-on-copy \
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
to see an overview, and you can get the diffs in the obvious way too.
Now you know everything we know :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"Ph. Marek" <ph...@bmlv.gv.at> writes:
> On Dienstag, 15. Juli 2008, Karl Fogel wrote:
>> You might have the wrong impression about how this group works...
> ...
>> Eventually, someone will probably do it. But that will happen when it's
>> important enough to a programmer to implement it, or important enough to
>> some company to pay a programmer to do it. That's how things happen here.
> Or, possibly, has already done that:
> http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
> owner-group-mode/
> text-time/
>
> If that's updated to work against trunk it could suffice ...
> (Or, IMO, maybe it's easier to take the changes on this branch and try to get
> them to work on trunk.)
Yes, sorry, I should have pointed that out. Ph. Marek has already
worked on this, but no maintainer has had time to evaluate the patches.
They're all above in the public repository, though. You can also do
svn log --stop-on-copy \
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
to see an overview, and you can get the diffs in the obvious way too.
Now you know everything we know :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Dienstag, 15. Juli 2008, Karl Fogel wrote:
> You might have the wrong impression about how this group works...
...
> Eventually, someone will probably do it. But that will happen when it's
> important enough to a programmer to implement it, or important enough to
> some company to pay a programmer to do it. That's how things happen here.
Or, possibly, has already done that:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
owner-group-mode/
text-time/
If that's updated to work against trunk it could suffice ...
(Or, IMO, maybe it's easier to take the changes on this branch and try to get
them to work on trunk.)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Dienstag, 15. Juli 2008, Karl Fogel wrote:
> You might have the wrong impression about how this group works...
...
> Eventually, someone will probably do it. But that will happen when it's
> important enough to a programmer to implement it, or important enough to
> some company to pay a programmer to do it. That's how things happen here.
Or, possibly, has already done that:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
owner-group-mode/
text-time/
If that's updated to work against trunk it could suffice ...
(Or, IMO, maybe it's easier to take the changes on this branch and try to get
them to work on trunk.)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"郭煜" <gu...@dscomm.com.cn> writes:
> At the same time , I find that you have discussed on this problem
> for several years. It's too long. But in my working plan charged by
> my boss, new version control system should be put into using no later
> than this year-end and I need three weeks to tryout, if there's no
> special instance. I like subversion best. Could you please discuss
> this problem again and reply to me before July.18 ? If the outcome is
> "no", I will not trouble you anymore.
You might have the wrong impression about how this group works...
We're not a group of people all in one building, having meetings every
week, etc. Instead, we're scattered around the world, we communicate
mostly by email, and a discussion can continue for years. So you won't
get a definite "no" or "yes". You'll just get various people saying
"Well, we might do it, but no promises, and we can't give a date."
Since Subversion is open-source software, your company is free to modify
it to add the file-modify-time feature. Of course, that's a lot of
work, which is why you want us to do it. And that's also why we want
you to do it :-).
Eventually, someone will probably do it. But that will happen when it's
important enough to a programmer to implement it, or important enough to
some company to pay a programmer to do it. That's how things happen here.
If you're interested in commercial support for Subversion, some vendors
are listed at http://subversion.tigris.org/commercial-support.html.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"郭煜" <gu...@dscomm.com.cn> writes:
> At the same time , I find that you have discussed on this problem
> for several years. It's too long. But in my working plan charged by
> my boss, new version control system should be put into using no later
> than this year-end and I need three weeks to tryout, if there's no
> special instance. I like subversion best. Could you please discuss
> this problem again and reply to me before July.18 ? If the outcome is
> "no", I will not trouble you anymore.
You might have the wrong impression about how this group works...
We're not a group of people all in one building, having meetings every
week, etc. Instead, we're scattered around the world, we communicate
mostly by email, and a discussion can continue for years. So you won't
get a definite "no" or "yes". You'll just get various people saying
"Well, we might do it, but no promises, and we can't give a date."
Since Subversion is open-source software, your company is free to modify
it to add the file-modify-time feature. Of course, that's a lot of
work, which is why you want us to do it. And that's also why we want
you to do it :-).
Eventually, someone will probably do it. But that will happen when it's
important enough to a programmer to implement it, or important enough to
some company to pay a programmer to do it. That's how things happen here.
If you're interested in commercial support for Subversion, some vendors
are listed at http://subversion.tigris.org/commercial-support.html.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear SVN dev-team,
Having read subversion dev-team's opinion, I understand your pressure of supporting file modification time from regulating the cooperation within software modules even third-party modules. I think that subversion-v2.0 like Mr.Phippard said is a good suggestion.
At the same time , I find that you have discussed on this problem for several years. It's too long. But in my working plan charged by my boss, new version control system should be put into using no later than this year-end and I need three weeks to tryout, if there's no special instance. I like subversion best. Could you please discuss this problem again and reply to me before July.18 ? If the outcome is "no", I will not trouble you anymore.
Waiting for your reply solicitously.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2503
Tel(M): 13916313249
----- Original Message -----
From: "Ben Collins-Sussman" <su...@red-bean.com>
To: <de...@subversion.tigris.org>
Cc: "郭煜" <gu...@dscomm.com.cn>; "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>
Sent: Friday, July 11, 2008 10:10 PM
Subject: Re: Subversion Problem - How to save file modify time?
> Julian: sounds like a good idea, I'll augment the FAQ.
>
> Ryan: you and guoy have made a fairly compelling case (to me, at
> least) that we should add a feature which at least saves the original
> mod-time of a file in some sort of property; that information
> wouldn't be totally lost.
>
> On Fri, Jul 11, 2008 at 3:45 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > Ben,
> >
> > This is a pretty well written answer to a Frequently Asked Question that
> > doesn't seem to be in <faq.html>. Fancy putting it there?
> >
> > - Julian
> >
> >
> > On Thu, 2008-07-10 at 21:43 -0500, 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:
> >>
> >> * 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.
> >>
> >> * Version control is typically used for code. 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.
> >>
> >> * 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.
> >>
> >> * If you want to be even friendlier to people without subversion, you
> >> can put $LastChangedDate$ or $Revision$ keywords directly into the
> >> files to be expanded.
> >>
> >> If none of these features satisifes your use-case, I'm curious to hear
> >> exactly what you're trying to accomplish, and why these solutions
> >> don't work for you.
> >>
> >>
> >>
> >>
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Mr. Unterberg,
> >> >
> >> >
> >> > Yes , I see that subversion support good functions but based on lost
> >> > file modify date. Is it?
> >> >
> >> > I like subversion client very much. But as an end user, we can't select
> >> > a version control system which can't save file modify date. Because this is
> >> > very important for our team-work in software developement progress. It's so
> >> > sorry.
> >> >
> >> > I think that you can get better idea yourself to shot the problem
> >> > later. Perhaps other version control system could be your referrence. If
> >> > this problem is ok, contract me as soon as you can please. We'll select
> >> > subversion as our version control system.
> >> >
> >> > Thanks & Best Regards,
> >> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> >> > Addr: 上海市平江路15号（zip:200050）
> >> > Tel(O): 86-21-64031580 x 2512
> >> > Tel(MB): 13916313249
> >> >
> >> > ----- Original Message -----
> >> > From: "Norbert Unterberg" <nu...@gmail.com>
> >> > To: "郭煜" <gu...@dscomm.com.cn>
> >> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> >> > Sent: Friday, July 11, 2008 5:06 AM
> >> > Subject: Re: Subversion Problem - How to save file modify time?
> >> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> >> > Dear Invendor,
> >> >> >
> >> >> > This is a software company in china. I'm an engineer at
> >> >> > develope-management department.
> >> >> >
> >> >> > We used other version control system as perforce or starteam before.
> >> >> > Now we are trying subversion.
> >> >> >
> >> >> > During trying subversion, we find that file modify time could not be
> >> >> > saved into subversion and get from subversion.
> >> >> >
> >> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> >> > problem. How to shot it, if a deploy problem.
> >> >> >
> >> >>
> >> >> There is a configuration option "use-commit-times" which you can find
> >> >> in the documentation, It does not preserve the real file modify time
> >> >> but the commit time which might be good enough.
> >> >> However, for software development, the default behaviour (file time is
> >> >> the time of last update or checkout) usually works best.
> >> >>
> >> >> The problem with preserving file modify time is that it is very hard
> >> >> to do right. What is the correct modify time if two people change the
> >> >> same file and then they commit/update/merge the data? What to do when
> >> >> merging a branch? IF SVN modifies the file contents during a commit
> >> >> (see svn:keyword property) does that count as a file modification or
> >> >> not?
> >> >>
> >> >> Norbert
> >> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
>
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear SVN dev-team,
Having read subversion dev-team's opinion, I understand your pressure of supporting file modification time from regulating the cooperation within software modules even third-party modules. I think that subversion-v2.0 like Mr.Phippard said is a good suggestion.
At the same time , I find that you have discussed on this problem for several years. It's too long. But in my working plan charged by my boss, new version control system should be put into using no later than this year-end and I need three weeks to tryout, if there's no special instance. I like subversion best. Could you please discuss this problem again and reply to me before July.18 ? If the outcome is "no", I will not trouble you anymore.
Waiting for your reply solicitously.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2503
Tel(M): 13916313249
----- Original Message -----
From: "Ben Collins-Sussman" <su...@red-bean.com>
To: <de...@subversion.tigris.org>
Cc: "郭煜" <gu...@dscomm.com.cn>; "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>
Sent: Friday, July 11, 2008 10:10 PM
Subject: Re: Subversion Problem - How to save file modify time?
> Julian: sounds like a good idea, I'll augment the FAQ.
>
> Ryan: you and guoy have made a fairly compelling case (to me, at
> least) that we should add a feature which at least saves the original
> mod-time of a file in some sort of property; that information
> wouldn't be totally lost.
>
> On Fri, Jul 11, 2008 at 3:45 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > Ben,
> >
> > This is a pretty well written answer to a Frequently Asked Question that
> > doesn't seem to be in <faq.html>. Fancy putting it there?
> >
> > - Julian
> >
> >
> > On Thu, 2008-07-10 at 21:43 -0500, 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:
> >>
> >> * 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.
> >>
> >> * Version control is typically used for code. 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.
> >>
> >> * 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.
> >>
> >> * If you want to be even friendlier to people without subversion, you
> >> can put $LastChangedDate$ or $Revision$ keywords directly into the
> >> files to be expanded.
> >>
> >> If none of these features satisifes your use-case, I'm curious to hear
> >> exactly what you're trying to accomplish, and why these solutions
> >> don't work for you.
> >>
> >>
> >>
> >>
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Mr. Unterberg,
> >> >
> >> >
> >> > Yes , I see that subversion support good functions but based on lost
> >> > file modify date. Is it?
> >> >
> >> > I like subversion client very much. But as an end user, we can't select
> >> > a version control system which can't save file modify date. Because this is
> >> > very important for our team-work in software developement progress. It's so
> >> > sorry.
> >> >
> >> > I think that you can get better idea yourself to shot the problem
> >> > later. Perhaps other version control system could be your referrence. If
> >> > this problem is ok, contract me as soon as you can please. We'll select
> >> > subversion as our version control system.
> >> >
> >> > Thanks & Best Regards,
> >> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> >> > Addr: 上海市平江路15号（zip:200050）
> >> > Tel(O): 86-21-64031580 x 2512
> >> > Tel(MB): 13916313249
> >> >
> >> > ----- Original Message -----
> >> > From: "Norbert Unterberg" <nu...@gmail.com>
> >> > To: "郭煜" <gu...@dscomm.com.cn>
> >> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> >> > Sent: Friday, July 11, 2008 5:06 AM
> >> > Subject: Re: Subversion Problem - How to save file modify time?
> >> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> >> > Dear Invendor,
> >> >> >
> >> >> > This is a software company in china. I'm an engineer at
> >> >> > develope-management department.
> >> >> >
> >> >> > We used other version control system as perforce or starteam before.
> >> >> > Now we are trying subversion.
> >> >> >
> >> >> > During trying subversion, we find that file modify time could not be
> >> >> > saved into subversion and get from subversion.
> >> >> >
> >> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> >> > problem. How to shot it, if a deploy problem.
> >> >> >
> >> >>
> >> >> There is a configuration option "use-commit-times" which you can find
> >> >> in the documentation, It does not preserve the real file modify time
> >> >> but the commit time which might be good enough.
> >> >> However, for software development, the default behaviour (file time is
> >> >> the time of last update or checkout) usually works best.
> >> >>
> >> >> The problem with preserving file modify time is that it is very hard
> >> >> to do right. What is the correct modify time if two people change the
> >> >> same file and then they commit/update/merge the data? What to do when
> >> >> merging a branch? IF SVN modifies the file contents during a commit
> >> >> (see svn:keyword property) does that count as a file modification or
> >> >> not?
> >> >>
> >> >> Norbert
> >> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
>
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Julian: sounds like a good idea, I'll augment the FAQ.
Ryan: you and guoy have made a fairly compelling case (to me, at
least) that we should add a feature which at least saves the original
mod-time of a file in some sort of property; that information
wouldn't be totally lost.
On Fri, Jul 11, 2008 at 3:45 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Ben,
>
> This is a pretty well written answer to a Frequently Asked Question that
> doesn't seem to be in <faq.html>. Fancy putting it there?
>
> - Julian
>
>
> On Thu, 2008-07-10 at 21:43 -0500, 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:
>>
>> * 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.
>>
>> * Version control is typically used for code. 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.
>>
>> * 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.
>>
>> * If you want to be even friendlier to people without subversion, you
>> can put $LastChangedDate$ or $Revision$ keywords directly into the
>> files to be expanded.
>>
>> If none of these features satisifes your use-case, I'm curious to hear
>> exactly what you're trying to accomplish, and why these solutions
>> don't work for you.
>>
>>
>>
>>
>> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> > Dear Mr. Unterberg,
>> >
>> >
>> > Yes , I see that subversion support good functions but based on lost
>> > file modify date. Is it?
>> >
>> > I like subversion client very much. But as an end user, we can't select
>> > a version control system which can't save file modify date. Because this is
>> > very important for our team-work in software developement progress. It's so
>> > sorry.
>> >
>> > I think that you can get better idea yourself to shot the problem
>> > later. Perhaps other version control system could be your referrence. If
>> > this problem is ok, contract me as soon as you can please. We'll select
>> > subversion as our version control system.
>> >
>> > Thanks & Best Regards,
>> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
>> > Addr: 上海市平江路15号（zip:200050）
>> > Tel(O): 86-21-64031580 x 2512
>> > Tel(MB): 13916313249
>> >
>> > ----- Original Message -----
>> > From: "Norbert Unterberg" <nu...@gmail.com>
>> > To: "郭煜" <gu...@dscomm.com.cn>
>> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
>> > Sent: Friday, July 11, 2008 5:06 AM
>> > Subject: Re: Subversion Problem - How to save file modify time?
>> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> >> > Dear Invendor,
>> >> >
>> >> > This is a software company in china. I'm an engineer at
>> >> > develope-management department.
>> >> >
>> >> > We used other version control system as perforce or starteam before.
>> >> > Now we are trying subversion.
>> >> >
>> >> > During trying subversion, we find that file modify time could not be
>> >> > saved into subversion and get from subversion.
>> >> >
>> >> > Is it a design problem or deploy problem ? I hope it's a deploy
>> >> > problem. How to shot it, if a deploy problem.
>> >> >
>> >>
>> >> There is a configuration option "use-commit-times" which you can find
>> >> in the documentation, It does not preserve the real file modify time
>> >> but the commit time which might be good enough.
>> >> However, for software development, the default behaviour (file time is
>> >> the time of last update or checkout) usually works best.
>> >>
>> >> The problem with preserving file modify time is that it is very hard
>> >> to do right. What is the correct modify time if two people change the
>> >> same file and then they commit/update/merge the data? What to do when
>> >> merging a branch? IF SVN modifies the file contents during a commit
>> >> (see svn:keyword property) does that count as a file modification or
>> >> not?
>> >>
>> >> Norbert
>> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Julian: sounds like a good idea, I'll augment the FAQ.
Ryan: you and guoy have made a fairly compelling case (to me, at
least) that we should add a feature which at least saves the original
mod-time of a file in some sort of property; that information
wouldn't be totally lost.
On Fri, Jul 11, 2008 at 3:45 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Ben,
>
> This is a pretty well written answer to a Frequently Asked Question that
> doesn't seem to be in <faq.html>. Fancy putting it there?
>
> - Julian
>
>
> On Thu, 2008-07-10 at 21:43 -0500, 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:
>>
>> * 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.
>>
>> * Version control is typically used for code. 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.
>>
>> * 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.
>>
>> * If you want to be even friendlier to people without subversion, you
>> can put $LastChangedDate$ or $Revision$ keywords directly into the
>> files to be expanded.
>>
>> If none of these features satisifes your use-case, I'm curious to hear
>> exactly what you're trying to accomplish, and why these solutions
>> don't work for you.
>>
>>
>>
>>
>> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> > Dear Mr. Unterberg,
>> >
>> >
>> > Yes , I see that subversion support good functions but based on lost
>> > file modify date. Is it?
>> >
>> > I like subversion client very much. But as an end user, we can't select
>> > a version control system which can't save file modify date. Because this is
>> > very important for our team-work in software developement progress. It's so
>> > sorry.
>> >
>> > I think that you can get better idea yourself to shot the problem
>> > later. Perhaps other version control system could be your referrence. If
>> > this problem is ok, contract me as soon as you can please. We'll select
>> > subversion as our version control system.
>> >
>> > Thanks & Best Regards,
>> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
>> > Addr: 上海市平江路15号（zip:200050）
>> > Tel(O): 86-21-64031580 x 2512
>> > Tel(MB): 13916313249
>> >
>> > ----- Original Message -----
>> > From: "Norbert Unterberg" <nu...@gmail.com>
>> > To: "郭煜" <gu...@dscomm.com.cn>
>> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
>> > Sent: Friday, July 11, 2008 5:06 AM
>> > Subject: Re: Subversion Problem - How to save file modify time?
>> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> >> > Dear Invendor,
>> >> >
>> >> > This is a software company in china. I'm an engineer at
>> >> > develope-management department.
>> >> >
>> >> > We used other version control system as perforce or starteam before.
>> >> > Now we are trying subversion.
>> >> >
>> >> > During trying subversion, we find that file modify time could not be
>> >> > saved into subversion and get from subversion.
>> >> >
>> >> > Is it a design problem or deploy problem ? I hope it's a deploy
>> >> > problem. How to shot it, if a deploy problem.
>> >> >
>> >>
>> >> There is a configuration option "use-commit-times" which you can find
>> >> in the documentation, It does not preserve the real file modify time
>> >> but the commit time which might be good enough.
>> >> However, for software development, the default behaviour (file time is
>> >> the time of last update or checkout) usually works best.
>> >>
>> >> The problem with preserving file modify time is that it is very hard
>> >> to do right. What is the correct modify time if two people change the
>> >> same file and then they commit/update/merge the data? What to do when
>> >> merging a branch? IF SVN modifies the file contents during a commit
>> >> (see svn:keyword property) does that count as a file modification or
>> >> not?
>> >>
>> >> Norbert
>> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Subversion Problem - How to save file modify time?
Posted by Julian Foad <ju...@btopenworld.com>.
Ben,
This is a pretty well written answer to a Frequently Asked Question that
doesn't seem to be in <faq.html>. Fancy putting it there?
- Julian
On Thu, 2008-07-10 at 21:43 -0500, 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:
>
> * 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.
>
> * Version control is typically used for code. 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.
>
> * 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.
>
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
>
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
>
>
>
>
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Mr. Unterberg,
> >
> >
> > Yes , I see that subversion support good functions but based on lost
> > file modify date. Is it?
> >
> > I like subversion client very much. But as an end user, we can't select
> > a version control system which can't save file modify date. Because this is
> > very important for our team-work in software developement progress. It's so
> > sorry.
> >
> > I think that you can get better idea yourself to shot the problem
> > later. Perhaps other version control system could be your referrence. If
> > this problem is ok, contract me as soon as you can please. We'll select
> > subversion as our version control system.
> >
> > Thanks & Best Regards,
> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> > Addr: 上海市平江路15号（zip:200050）
> > Tel(O): 86-21-64031580 x 2512
> > Tel(MB): 13916313249
> >
> > ----- Original Message -----
> > From: "Norbert Unterberg" <nu...@gmail.com>
> > To: "郭煜" <gu...@dscomm.com.cn>
> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> > Sent: Friday, July 11, 2008 5:06 AM
> > Subject: Re: Subversion Problem - How to save file modify time?
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Invendor,
> >> >
> >> > This is a software company in china. I'm an engineer at
> >> > develope-management department.
> >> >
> >> > We used other version control system as perforce or starteam before.
> >> > Now we are trying subversion.
> >> >
> >> > During trying subversion, we find that file modify time could not be
> >> > saved into subversion and get from subversion.
> >> >
> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> > problem. How to shot it, if a deploy problem.
> >> >
> >>
> >> There is a configuration option "use-commit-times" which you can find
> >> in the documentation, It does not preserve the real file modify time
> >> but the commit time which might be good enough.
> >> However, for software development, the default behaviour (file time is
> >> the time of last update or checkout) usually works best.
> >>
> >> The problem with preserving file modify time is that it is very hard
> >> to do right. What is the correct modify time if two people change the
> >> same file and then they commit/update/merge the data? What to do when
> >> merging a branch? IF SVN modifies the file contents during a commit
> >> (see svn:keyword property) does that count as a file modification or
> >> not?
> >>
> >> Norbert
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Mark Reibert <sv...@reibert.com>.
On Thu, 2008-07-17 at 08:38 +0200, Oliver Betz wrote:
> John Aldridge wrote:
>
> >Ben Collins-Sussman wrote:
> >I'm actually slightly surprised that the people using subversion for
> >storing photographs aren't more interested in the creation date than the
> >last modified data, for example.
>
> mtime is the default used by nearly everything, e.g. ls, the Windows
> explorer, file managers, picture viewers etc.
Moreover, there is no such thing as creation time (at least in Linux - I
don't know about Windows).
bash$ touch foo ; stat foo ; sleep 10 ; chmod 444 foo ; stat foo
File: `foo'
Size: 0 Blocks: 8 IO Block: 4096 regular
empty file
Device: fd00h/64768d Inode: 692575 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 5000/ mark) Gid: ( 100/ users)
Access: 2008-07-17 00:53:59.000000000 -0700
Modify: 2008-07-17 00:53:59.000000000 -0700
Change: 2008-07-17 00:53:59.000000000 -0700
File: `foo'
Size: 0 Blocks: 8 IO Block: 4096 regular
empty file
Device: fd00h/64768d Inode: 692575 Links: 1
Access: (0444/-r--r--r--) Uid: ( 5000/ mark) Gid: ( 100/ users)
Access: 2008-07-17 00:53:59.000000000 -0700
Modify: 2008-07-17 00:53:59.000000000 -0700
Change: 2008-07-17 00:54:09.000000000 -0700
--
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Oliver Betz <li...@gmx.net>.
John Aldridge wrote:
>Ben Collins-Sussman wrote:
>> I think you're right: even if Subversion doesn't make any use of the
>> file's original mod-time, it could at least be saved in a property so
>> the information isn't lost completely.
>
>Not to disagree with this[1], but what about other file metadata such as
>creation time, file permissions, file owner, ACLs ... ?
has also been discussed in the past IIRC. It's a matter of
benefit/effort.
>I'm actually slightly surprised that the people using subversion for
>storing photographs aren't more interested in the creation date than the
>last modified data, for example.
mtime is the default used by nearly everything, e.g. ls, the Windows
explorer, file managers, picture viewers etc.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by John Aldridge <jo...@informatix.co.uk>.
Ben Collins-Sussman wrote:
> I think you're right: even if Subversion doesn't make any use of the
> file's original mod-time, it could at least be saved in a property so
> the information isn't lost completely.
Not to disagree with this[1], but what about other file metadata such as
creation time, file permissions, file owner, ACLs ... ?
I'm actually slightly surprised that the people using subversion for
storing photographs aren't more interested in the creation date than the
last modified data, for example.
--
Cheers,
John
[1] Although I, personally, have no need for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Subversion Problem - How to sav
Karl Fogel wrote on 11 Jul 2008, 11:33, at least in part:
> I don't understand why we're arguing so hard that this feature must
> never be in Subversion.
>
> It's fine to say "It's not important enough to any current developer
> to devote time to it." That's clearly true. It's also fine to say
> "If you want to hire someone competent to see this feature all the way
> through design and coding, then patches welcome." We say this all the
> time.
>
> But I'm a little surprised that we're so vehement about insisting that
> this is not useful, when we keep hearing from users that it is useful.
> It reminds me of all the years when CVS and SVN experts would tell
> people "You don't really need locking." Then SVN added a good locking
> implementation, and lo and behold, a lot of people use it.
>
> We could make the argument that mod-time-preservation would add too
> much instability to the code. But that's a bit spurious: first, we
> haven't seen the patch, so why would we be so sure? Second, we've
> incorporated lots of other features that don't appeal to all users and
> do touch a fair amount of code (look at all the different auth
> mechanisms we support).
>
> When I think about this feature technically, it doesn't seem likely to
> add much instability. After all, if we're willing to save the modtime
> in a property (an idea which Ben has proposed and which no one seems
> to object to), then how hard would it be to use the value of that
> property to set -- on platforms that support it -- the modtime of the
> working file on checkout, update, or revert? Are we really talking
> about rocket science here?
>
> I'm not saying that anyone needs to drop what they're doing and write
> the patch. I'm certainly not planning to. There is no obligation to
> do something just because someone's asking for it.
>
> But we also don't need to harden passive inaction into active
> resistance. If some developer were to make a clean patch to do this,
> I don't think we should turn it down on the assumption that it adds
> instability. We should just evaluate it like any other feature patch,
> and incorporate it if it seems good.
>
> If there's going to be a FAQ entry here, IMHO it should something more
> along the lines of what I'm saying here, not "We've discussed this and
> decided it will never be in Subversion". There are feature proposals
> that deserve that kind of unconditional rejection, but this is not one
> of them.
>
> -Karl
Karl,
thanks a lot for these words, all of them!
Have a fine day,
Jan Hendrik
---------------------------------------
Freedom quote:
Manche Leute halten den Unternehmer für einen räudigen Wolf,
den man totschlagen müsse. Andere sehen in ihm eine Kuh,
die man ununterbrochen melken könne.
Nur wenige erkennen in ihm das Pferd, das den Karren zieht.
-- Sir Winston Churchill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Oliver Betz <li...@gmx.net>.
Les Mikesell wrote:
[...]
>> In theory revision properties could be used, but do we really want an
>> import of 10,000 files sticking all of that data into revision
>> properties?
>
>Or worse, if you accidentally do something that touches the timestamps
>on your working directory (perhaps copying to a new location) and
...without specifying -p...
If a user does this without version control, he is also out of luck.
Using Windows most times, I'm safe from _such_ accidents.
>commit, should that be a new revision for every file?
A warning could be issued if mtimes are changed and content is still
the same. Subversion already does this check during commit, isn't it?
I'm not sure whether it's worth the effort. Maybe it's possible with a
pre-commit hook.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Erik Huelsmann wrote on Sat, 12 Jul 2008 at 07:44 +0200:
> On Sat, Jul 12, 2008 at 3:21 AM, Les Mikesell <le...@gmail.com> wrote:
> > I don't get it... You want to check out another copy of content to add a new
> > server to a farm. How is this approach going to mesh with the
> > 'get-if-newer' requests coming in browsers that have already cached a copy
> > from an existing server - or that will subsequently hit other servers after
> > loading this copy?
>
> AH! But that use-case is just as easily solved by using
> use-commit-times! Because then too, on both servers, the timestamps
> will be equal. So no new Subversion functionality is required to
> address this problem.
Shouldn't the FAQ #website-auto-update recommend to set
use-commit-times=yes, then?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Erik Huelsmann <eh...@gmail.com>.
On Sat, Jul 12, 2008 at 3:21 AM, Les Mikesell <le...@gmail.com> wrote:
> Reedick, Andrew wrote:
>
>> As for the Webserver farm example, it's "bogus." Using timestamps to
>> detect changed files isn't reliable (especially when you consider clock
>> skew.) Checksums are a better idea. Use 'svn info' to get the md5 of
>> the files that comprise the baseline. Compare the svn checksums against
>> the production file checksums. Only deploy files with mismatched
>> checksums. Problem solved without the use of unreliable timestamps or
>> commit-times.
>
> I don't get it... You want to check out another copy of content to add a new
> server to a farm. How is this approach going to mesh with the
> 'get-if-newer' requests coming in browsers that have already cached a copy
> from an existing server - or that will subsequently hit other servers after
> loading this copy?
AH! But that use-case is just as easily solved by using
use-commit-times! Because then too, on both servers, the timestamps
will be equal. So no new Subversion functionality is required to
address this problem.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Reedick, Andrew wrote:
> As for the Webserver farm example, it's "bogus." Using timestamps to
> detect changed files isn't reliable (especially when you consider clock
> skew.) Checksums are a better idea. Use 'svn info' to get the md5 of
> the files that comprise the baseline. Compare the svn checksums against
> the production file checksums. Only deploy files with mismatched
> checksums. Problem solved without the use of unreliable timestamps or
> commit-times.
I don't get it... You want to check out another copy of content to add a
new server to a farm. How is this approach going to mesh with the
'get-if-newer' requests coming in browsers that have already cached a
copy from an existing server - or that will subsequently hit other
servers after loading this copy?
> In fact, you can fake out 'svn status' with timestamps. 'svn status'
> looks at the file timestamp (and maybe the size too) to determine if a
> file has been modified. So it's possible to modify a workspace file,
> use touch to restore the original timestamp, and svn will never
> notice...
Yes, there is a philosophical disconnect between svn itself depending on
timestamps internally and refusing to preserve them for other tools.
> Personally, the only use I have for preserving original timestamps is
> because it looks pretty.
Do you ever use a browser? A proxy cache? A web server that recompiles
and internally caches pages when they are modified?
> IMO, timestamps are a catch-22. They're either useful in very
> unimportant situations, in which case no one really cares if they're not
> preserved, or they're super-important, in which case you're admitting
> that you're relying on a very unreliable piece of information for
> critical processes instead of taking the time to implement something
> more robust and accurate, such as checksums.
Just about everything that has any concept of caching will use
timestamps as the only reasonably quick method to determine the need to
get a fresh copy. In many cases using commit time would be suitable to
maintain a consistent view, though - or having only one master checkout
with rsync or some other transport for the other instances.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion Problem - How to save file modify time?
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Friday, July 11, 2008 12:11 PM
> To: Mark Phippard
> Cc: Ben Collins-Sussman; Karl Fogel; users@subversion.tigris.org; Ryan
> Schmidt; ??; Norbert Unterberg
> Subject: Re: Subversion Problem - How to save file modify time?
>
>
> Did those systems do anything sensible when then committing system
> clocks were in the wrong century or if files were dated in the future?
> One advantage of using commit times is that they can be forced to be
> consistent.
>
<tongue_in_cheek>
Anyone who uses Subversion in spite of Subversion's less than
bulletproof merging and merge tracking, won't be too concerned about
bogus timestamps.
</tongue_in_cheek>
As for the Webserver farm example, it's "bogus." Using timestamps to
detect changed files isn't reliable (especially when you consider clock
skew.) Checksums are a better idea. Use 'svn info' to get the md5 of
the files that comprise the baseline. Compare the svn checksums against
the production file checksums. Only deploy files with mismatched
checksums. Problem solved without the use of unreliable timestamps or
commit-times.
In fact, you can fake out 'svn status' with timestamps. 'svn status'
looks at the file timestamp (and maybe the size too) to determine if a
file has been modified. So it's possible to modify a workspace file,
use touch to restore the original timestamp, and svn will never
notice...
Personally, the only use I have for preserving original timestamps is
because it looks pretty. It could also be useful for vendor code or
external code. There's no guarantee that the vendor/external code was
versioned properly or distributed using good configuration management
practices, so a timestamp could become a crucial piece of research
information. But then you can always check-in a snapshot of 'ls -al'.
But that's clumsy and relies on a manual process to preserve
pre-versioned meta-data. Meh.
Another potential use for timestamps is to preserve order. A series of
images might only make sense when viewed in time order. Of course this
assumes you didn't add a sequence number to the filename for some
reason. And since timestamps aren't written in stone, it's not a
reliable method.
IMO, timestamps are a catch-22. They're either useful in very
unimportant situations, in which case no one really cares if they're not
preserved, or they're super-important, in which case you're admitting
that you're relying on a very unreliable piece of information for
critical processes instead of taking the time to implement something
more robust and accurate, such as checksums.
A possible alternative would be for the OS to maintain a standard
checksum. Instead of comparing the OS timestamp to the SVN timestamp,
you would be comparing the OS checksum to the SVN checksum.
> > My problem with this
> > has always been the design. I do not think you can do this feature
> > properly on top of Subversion's repository today.
>
> > Using a versioned property sucks. That means you have to carry
> around
> > the property information in the working copy and every commit in
> > theory needs to update it. This fouls log and diff etc..
>
> It would be nice to have the value stored whether you use it or not,
> though, with tools to view it and restore it even if you don't restore
> by default.
Maybe a hidden property? Generally speaking, file timestamps are only
useful outside of Subversion. Diff and log shouldn't care, whereas ls
would want to display timestamps.
> Or worse, if you accidentally do something that touches the timestamps
> on your working directory (perhaps copying to a new location) and
> commit, should that be a new revision for every file?
Make it an optional argument or setting. IIRC, in ClearCase you could
force a check-in of an unchanged file. There was also the "-ptime"
option on check-in which would allow you to preserve the file's actual
timestamp, instead of defaulting to the commit time. Whereas on the
checkout, "-ptime" would restore the file with the saved timestamp
instead of current time.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Mark Phippard wrote:
>>
>> I'm fine for reopening the debate; we should first examine why
>> exactly we've kept this branch in stasis for so long. If we don't
>> like the design, what would a better design be?
>
> Having used other version control systems that have this feature, I
> always thought Subversion should have it too.
Did those systems do anything sensible when then committing system
clocks were in the wrong century or if files were dated in the future?
One advantage of using commit times is that they can be forced to be
consistent.
> My problem with this
> has always been the design. I do not think you can do this feature
> properly on top of Subversion's repository today.
> Using a versioned property sucks. That means you have to carry around
> the property information in the working copy and every commit in
> theory needs to update it. This fouls log and diff etc..
It would be nice to have the value stored whether you use it or not,
though, with tools to view it and restore it even if you don't restore
by default.
> In theory revision properties could be used, but do we really want an
> import of 10,000 files sticking all of that data into revision
> properties?
Or worse, if you accidentally do something that touches the timestamps
on your working directory (perhaps copying to a new location) and
commit, should that be a new revision for every file?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 11:45 AM -0400 7/11/08, Mark Phippard wrote:
>On Fri, Jul 11, 2008 at 11:37 AM, Ben Collins-Sussman
><su...@red-bean.com> wrote:
> > Given that we've allowed a user to maintain a branch for this
> > feature for *years* -- without allowing him to merge the
> > feature -- our actions speak louder than words!
> >
>> I'm fine for reopening the debate; we should first examine why
>> exactly we've kept this branch in stasis for so long. If we don't
>> like the design, what would a better design be?
>
>Having used other version control systems that have this feature, I
>always thought Subversion should have it too. My problem with this
>has always been the design. I do not think you can do this feature
>properly on top of Subversion's repository today.
>
>Using a versioned property sucks. That means you have to carry
>around the property information in the working copy and every commit
>in theory needs to update it. This fouls log and diff etc..
>
>In theory revision properties could be used, but do we really want
>an import of 10,000 files sticking all of that data into revision
>properties? In addition, we do not have any great ways to access that
>data and it would add a lot of extra overhead during checkout/update
>operations to go find this information in the revision properties.
I'm also wondering how a versioned-property like this would be
handled when doing merges. Disclaimer: I've done very little with
merge-tracking, so the problem here may be my own ignorance. But I
assume you wouldn't want to merge the last-mod time from one branch
to another one.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 11, 2008 at 11:37 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> Given that we've allowed a user to maintain a branch for this feature
> for *years* -- without allowing him to merge the feature -- our
> actions speak louder than words!
>
> I'm fine for reopening the debate; we should first examine why
> exactly we've kept this branch in stasis for so long. If we don't
> like the design, what would a better design be?
Having used other version control systems that have this feature, I
always thought Subversion should have it too. My problem with this
has always been the design. I do not think you can do this feature
properly on top of Subversion's repository today.
Using a versioned property sucks. That means you have to carry around
the property information in the working copy and every commit in
theory needs to update it. This fouls log and diff etc..
In theory revision properties could be used, but do we really want an
import of 10,000 files sticking all of that data into revision
properties? In addition, we do not have any great ways to access that
data and it would add a lot of extra overhead during checkout/update
operations to go find this information in the revision properties.
To me, both of these problems are also why it is bogus to tell users
this is something they can do themselves using scripts or their own
clients. That really is not true because we do not provide an
adequate way to store this information.
I think this should be on our list for 2.0 so that there could be a
way to accommodate this information in the repository design. I think
the repository should gather and store this information regardless as
to whether the user wants it or not. The bit that should be exposed
to the user as an option would be whether or not to update the mtime
in the working copy on checkout/update. This is more or less how the
tools that have this feature seem to do it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Robert Blair <sv...@listemail.net>.
** Reply to message from Karl Fogel <kf...@red-bean.com> on Fri, 11 Jul 2008
11:53:21 -0400
> "Ben Collins-Sussman" <su...@red-bean.com> writes:
> > Given that we've allowed a user to maintain a branch for this feature
> > for *years* -- without allowing him to merge the feature -- our
> > actions speak louder than words!
> >
> > I'm fine for reopening the debate; we should first examine why
> > exactly we've kept this branch in stasis for so long. If we don't
> > like the design, what would a better design be?
>
> Oh, I think that has more to do with the specific code on the branch
> than anything else. I haven't looked at the design in a long time;
> Mark Phippard's concerns (posted in another mail) about using versioned
> properties are certainly important.
>
> I didn't mean to start a design discussion. I wasn't trying to change
> our development priorities by my post. I was merely saying that "no
> one's doing this right now" need not mean "we'll never do this".
I have seen messages stating the the repository data structure is being
changed. Would that be a good time to add the necessary fields to hold the
files dates? It will not satisfy those that want the feature now but would
allow someone to add the feature later without the objections that are not
being put forth now.
--
Robert Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"Robert Blair" <sv...@listemail.net> writes:
> I have seen messages stating the the repository data structure is being
> changed. Would that be a good time to add the necessary fields to hold the
> files dates? It will not satisfy those that want the feature now but would
> allow someone to add the feature later without the objections that are not
> being put forth now.
I don't think so. The repository structure is not the main issue here,
and without a real design, we wouldn't know how or if we should modify
it anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> Given that we've allowed a user to maintain a branch for this feature
> for *years* -- without allowing him to merge the feature -- our
> actions speak louder than words!
>
> I'm fine for reopening the debate; we should first examine why
> exactly we've kept this branch in stasis for so long. If we don't
> like the design, what would a better design be?
Oh, I think that has more to do with the specific code on the branch
than anything else. I haven't looked at the design in a long time;
Mark Phippard's concerns (posted in another mail) about using versioned
properties are certainly important.
I didn't mean to start a design discussion. I wasn't trying to change
our development priorities by my post. I was merely saying that "no
one's doing this right now" need not mean "we'll never do this".
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Given that we've allowed a user to maintain a branch for this feature
for *years* -- without allowing him to merge the feature -- our
actions speak louder than words!
I'm fine for reopening the debate; we should first examine why
exactly we've kept this branch in stasis for so long. If we don't
like the design, what would a better design be?
On Fri, Jul 11, 2008 at 10:33 AM, Karl Fogel <kf...@red-bean.com> wrote:
> I don't understand why we're arguing so hard that this feature must
> never be in Subversion.
>
> It's fine to say "It's not important enough to any current developer to
> devote time to it." That's clearly true. It's also fine to say "If you
> want to hire someone competent to see this feature all the way through
> design and coding, then patches welcome." We say this all the time.
>
> But I'm a little surprised that we're so vehement about insisting that
> this is not useful, when we keep hearing from users that it is useful.
> It reminds me of all the years when CVS and SVN experts would tell
> people "You don't really need locking." Then SVN added a good locking
> implementation, and lo and behold, a lot of people use it.
>
> We could make the argument that mod-time-preservation would add too much
> instability to the code. But that's a bit spurious: first, we haven't
> seen the patch, so why would we be so sure? Second, we've incorporated
> lots of other features that don't appeal to all users and do touch a
> fair amount of code (look at all the different auth mechanisms we
> support).
>
> When I think about this feature technically, it doesn't seem likely to
> add much instability. After all, if we're willing to save the modtime
> in a property (an idea which Ben has proposed and which no one seems to
> object to), then how hard would it be to use the value of that property
> to set -- on platforms that support it -- the modtime of the working
> file on checkout, update, or revert? Are we really talking about rocket
> science here?
>
> I'm not saying that anyone needs to drop what they're doing and write
> the patch. I'm certainly not planning to. There is no obligation to do
> something just because someone's asking for it.
>
> But we also don't need to harden passive inaction into active
> resistance. If some developer were to make a clean patch to do this, I
> don't think we should turn it down on the assumption that it adds
> instability. We should just evaluate it like any other feature patch,
> and incorporate it if it seems good.
>
> If there's going to be a FAQ entry here, IMHO it should something more
> along the lines of what I'm saying here, not "We've discussed this and
> decided it will never be in Subversion". There are feature proposals
> that deserve that kind of unconditional rejection, but this is not one
> of them.
>
> -Karl
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Karl Fogel <kf...@red-bean.com>.
I don't understand why we're arguing so hard that this feature must
never be in Subversion.
It's fine to say "It's not important enough to any current developer to
devote time to it." That's clearly true. It's also fine to say "If you
want to hire someone competent to see this feature all the way through
design and coding, then patches welcome." We say this all the time.
But I'm a little surprised that we're so vehement about insisting that
this is not useful, when we keep hearing from users that it is useful.
It reminds me of all the years when CVS and SVN experts would tell
people "You don't really need locking." Then SVN added a good locking
implementation, and lo and behold, a lot of people use it.
We could make the argument that mod-time-preservation would add too much
instability to the code. But that's a bit spurious: first, we haven't
seen the patch, so why would we be so sure? Second, we've incorporated
lots of other features that don't appeal to all users and do touch a
fair amount of code (look at all the different auth mechanisms we
support).
When I think about this feature technically, it doesn't seem likely to
add much instability. After all, if we're willing to save the modtime
in a property (an idea which Ben has proposed and which no one seems to
object to), then how hard would it be to use the value of that property
to set -- on platforms that support it -- the modtime of the working
file on checkout, update, or revert? Are we really talking about rocket
science here?
I'm not saying that anyone needs to drop what they're doing and write
the patch. I'm certainly not planning to. There is no obligation to do
something just because someone's asking for it.
But we also don't need to harden passive inaction into active
resistance. If some developer were to make a clean patch to do this, I
don't think we should turn it down on the assumption that it adds
instability. We should just evaluate it like any other feature patch,
and incorporate it if it seems good.
If there's going to be a FAQ entry here, IMHO it should something more
along the lines of what I'm saying here, not "We've discussed this and
decided it will never be in Subversion". There are feature proposals
that deserve that kind of unconditional rejection, but this is not one
of them.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Yves" == Yves Dorfsman <yv...@zioup.com> writes:
Yves> The one place I can see value to this is a directory where
Yves> users have been copying a file as file.c.1 file.c.2 file.c.3,
Yves> etc... I have had one case like this, and as I did not have
Yves> anything else available I used RCS to save the different
Yves> revisions. When I checked the log, I was pleasantly surprised
Yves> to see that RCS had used the name of the file owners and mtime
Yves> as the check in date rather than my name and the date of the
Yves> day.
That's just plain wrong. I didn't think RCS was that badly broken.
Preserving mtime is a reasonable feature, but lying about the checkin
time is a bug. It may be a design bug.
Ditto the name. A way to override the default checkin author is fair
enough, but silently making up something else is wrong.
By the way, in Subversion you can set the checkin author, it's a
revision property -- provided that the pre-revprop-change hook gives
you permission.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Yves Dorfsman <yv...@zioup.com>.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Oliver Betz <li...@gmx.net>.
John Peacock wrote:
>> But in many other cases, mtime is a _very valuable_ information and
>> shall be conserved. Photographs and DLLs are both examples where the
>> file creation occurs far from commit and therefore commit time isn't a
>> viable alternative.
>
>Photographs and DLL's typically have meta-data tags contained within the file so
>the information is not lost, just not as easily accessible as you might like.
for photographs, it's a real mess, especially handling timezone (and
DST) adjustments. I don't want to do this manually everytime after a
checkout, it's hard enough when I transfer the files from
FAT-something to a UTC based file system.
>> I also see that there are pitfalls, and I hope that the subversion
>> developers find a stable and useful solution.
>>
>> BTW: I also wondered why there is "active resistance" against
>> preserving mtime.
>
>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).
You refuse the feature because it could harm if activated by accident?
Isn't the already available possibility to set the mtime to the
commit-time as dangerous?
This accident (rather hard to achieve) would break make for the
moment, but this would be easy to repair (rebuild / touch).
>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
The "issues" you mentioned are minor. Bigger problems of mtime
versioning already have been discussed.
>no question that the feature will get added. But that hasn't happened yet, and
Philipp Marek comes to mind.
>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.
I appreciate this, but it doesn't change my impression.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by John Peacock <jo...@havurah-software.org>.
Oliver Betz wrote:
> But in many other cases, mtime is a _very valuable_ information and
> shall be conserved. Photographs and DLLs are both examples where the
> file creation occurs far from commit and therefore commit time isn't a
> viable alternative.
Photographs and DLL's typically have meta-data tags contained within the file so
the information is not lost, just not as easily accessible as you might like.
> I also see that there are pitfalls, and I hope that the subversion
> developers find a stable and useful solution.
>
> BTW: I also wondered why there is "active resistance" against
> preserving mtime.
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.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 17, 2008, at 02:56, Benjamin Smith-Mannschott wrote:
> My worry with 'preserving mtime' in the repository, is that it's not
> clearly defined what this should mean.
>
> We have an n to 1 mapping problem: We have one date to work with on
> the local file system: mtime, but at least three meanings we might
> want to give it:
>
> (1) The time, local to the working copy, when this file was last
> updated there. (the current default).
>
> (2) The time, local to the server, when the file was last committed.
>
> (3) The time, local to the working copy, that the file claimed to have
> as its mtime the last time it was comitted.
>
> Currently, we have (1) and (2) available. For my purposes, (2) seems
> the most natural, though (1) is the default.
>
> What people seem to be asking for is (3), but what exactly do they
> mean when they ask for this?
All I care about is preserving existing historical information on
import or add. I have songs I wrote four years ago, php projects I
developed three years ago, photos I took last year, and I want to
import them into a Subversion repository now, and I do not want to
lose the modification date and time currently on those files. After
they're in the repository, I'm perfectly happy with what Subversion
already provides, preserving the commit time and not the modification
time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On Jul 14, 2008, at 11:49, Oliver Betz wrote:
> "Ben Collins-Sussman" wrote:
> [...]
> > I think you're right: even if Subversion doesn't make any use of
> > the file's original mod-time, it could at least be saved in a
> > property so the information isn't lost completely.
> I'm glad to see that you also support this idea.
> [...]
> > Yes, that's exactly what it expands to. The philosophy is that
> > once objects become version controlled, the only "true" timestamps
> > which matter are the ones the repository, since the repository is
> > tracking all changes. Working copies are but shadows on the wall,
> > which can optionally be made to reflect repository timestamps.
> This philosophy is perfectly well suited for "code" in most cases
> (and I share your guess that SVN is mostly used for "code").
> But in many other cases, mtime is a _very valuable_ information and
> shall be conserved. Photographs and DLLs are both examples where the
> file creation occurs far from commit and therefore commit time isn't
> a viable alternative.
My experience is quite the opposite. mtime is almost worthless
information, except across relatively short time spans. It's simply
too fragile.
Photos: I have my cameras set to GMT and rename the
photos to an ISO8601 timestamp drived from the time stored in the JPEG
metadata upon import. This way the information about when the photo
was taken can no longer get stomped by some clumbsy program or file
system operation.
Build products: Ditto. We build our java artifacts with maven, so they
have version numbers or time-stamps in their names, which correspond
to tags in the repo. During deployment the version information is
removed from the names by the guy doing it, so sometimes he doesn't
know what f****ing version he's running, but at least I can check by
comparing MD5s to the verisons archived in the maven build repository.
(Interestingly, I can't rebuild from the tag and then compare MD5s
because JAR files store the mtime of the class files created by the
compiler and this is, naturally, the time when the compiler created
them. You weren't seriously expecting the compiler to use the mtime of
the corresponding source files for the resulting class files, were
you?)
Next issue: he had this idea that when deploying, he'd only have to
replace artifacts with newer modification times than what was already
deployed.
Query: what does "newer" mean when you've got more than one branch
being worked on? Has anyone considered that? I think he spent a week
testing the release version, when he should have been testing the
development version because the most recent builds of both were built
at the same time (on a multi-cpu box).
In short: I'm suspicious of any workflow that relies critically on
mtimes. I've seen too many things break from an over reliance on such
ephemera.
On Jul 14, 2008, at 11:49, Oliver Betz wrote:
> I also see that there are pitfalls, and I hope that the subversion
> developers find a stable and useful solution.
> BTW: I also wondered why there is "active resistance" against
> preserving mtime.
My worry with 'preserving mtime' in the repository, is that it's not
clearly defined what this should mean.
We have an n to 1 mapping problem: We have one date to work with on
the local file system: mtime, but at least three meanings we might
want to give it:
(1) The time, local to the working copy, when this file was last
updated there. (the current default).
(2) The time, local to the server, when the file was last committed.
(3) The time, local to the working copy, that the file claimed to have
as its mtime the last time it was comitted.
Currently, we have (1) and (2) available. For my purposes, (2) seems
the most natural, though (1) is the default.
What people seem to be asking for is (3), but what exactly do they
mean when they ask for this?
(a) I check out a file and then touch it, changing the mtime without
changing the contents.
Is my working copy now dirty? Is this a local modification? Do I
have a change that needs to be checked in?
Will svn revert turn the mtime back?
(b) My local clock is set to October 10, 2010. I modify a file and
check it in. What happens? Does the repo preserve this? Does it
complain?
(c) My colleague's PC has a balky clock battery. He modifies the file
and and checks it in: January 1, 1970. Should the repo respect
this too? Can I change a file in the past after I've changed it
in the future?
If this sort of thing is expected to work, then mtime perserved in the
repository is really just an property that the client happens to use
to clobber the working-copy-local mtime on checkout.
How does such a property behave on merging? Since a merge makes local
edits, which are then committed surely it's allowed to change in the
working copy. But, is that the time stamp that gets committed, or
should it be one of the other two? Or something completely different?
In short: I find option 3 (preserve working-copy mtime) worryingly
ill-defined. I haven't quite understood why option 2 (impose
last-modified time as working-copy mtime on update) isn't good enough
for the use-cases asking for option 3.
// Ben (bpsm)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Oliver Betz <li...@gmx.net>.
"Ben Collins-Sussman" wrote:
[...]
>I think you're right: even if Subversion doesn't make any use of the
>file's original mod-time, it could at least be saved in a property so
>the information isn't lost completely.
I'm glad to see that you also support this idea.
[...]
>Yes, that's exactly what it expands to. The philosophy is that once
>objects become version controlled, the only "true" timestamps which
>matter are the ones the repository, since the repository is tracking
>all changes. Working copies are but shadows on the wall, which can
>optionally be made to reflect repository timestamps.
This philosophy is perfectly well suited for "code" in most cases (and
I share your guess that SVN is mostly used for "code").
But in many other cases, mtime is a _very valuable_ information and
shall be conserved. Photographs and DLLs are both examples where the
file creation occurs far from commit and therefore commit time isn't a
viable alternative.
I also see that there are pitfalls, and I hope that the subversion
developers find a stable and useful solution.
BTW: I also wondered why there is "active resistance" against
preserving mtime.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, Jul 11, 2008 at 2:37 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>> * 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.
>
> 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.
I think you're right: even if Subversion doesn't make any use of the
file's original mod-time, it could at least be saved in a property so
the information isn't lost completely.
>
>
>> * Version control is typically used for code. 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.
Uh, but does the default behavior (of being kind to compiled
languages) actually have any negative affect on interpreted languages?
I can't see any, so this seems like a good default behavior to me.
>
> Also, not all repositories contain code. I have a second repository for
> musical compositions, for example.
Me too. :-)
>
>
>> * 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.
>
Yep, and I would recommend that people using svn to manage websites
turn on use-commit-times=true. That's one of the main use-cases for
that feature.
That said, I'm willing to wager that across the board, svn is used
much more often to manage code than websites, hence the default of
use-commit-times=false.
>
>> * If you want to be even friendlier to people without subversion, you
>> can put $LastChangedDate$ or $Revision$ keywords directly into the
>> files to be expanded.
>
> To be completely pedantic :) it seems like $LastChangedDate$ does not show
> the date the file was last changed by the author. It shows the date the file
> was last committed. I guess you could say it's the date the file was last
> changed in the repository.
Yes, that's exactly what it expands to. The philosophy is that once
objects become version controlled, the only "true" timestamps which
matter are the ones the repository, since the repository is tracking
all changes. Working copies are but shadows on the wall, which can
optionally be made to reflect repository timestamps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Oliver Betz <li...@gmx.net>.
Ryan Schmidt wrote:
[...]
>> * 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.
Ack. Therefore I made a small perl script which commits one file at a
time, setting the commit time property to the file mtime. It should be
somewhere in the archives of this list.
[...]
>Also, not all repositories contain code. I have a second repository
>for musical compositions, for example.
This kind of data is one of the reasons I vote strongly for versioning
the modification time.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.
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.
> * Version control is typically used for code. 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.
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
To be completely pedantic :) it seems like $LastChangedDate$ does not
show the date the file was last changed by the author. It shows the
date the file was last committed. I guess you could say it's the date
the file was last changed in the repository.
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2008-07-18 at 07:21 -0700, Kean Johnston wrote:
> automake injects rules into the Makefile.in files that will cause it
> to re-run the autoconf/automake/libtoolize programs if it detects that
> configure.ac is more modern than configure, or if a Makefile.am is more
> modern than its corresponding Makefile.in.
I've run into this case myself, with CVS.
My workaround was to, while preparing checked out sources for build,
force all of the file timestamps to the current time, which prevents
make from deciding that any of the sources are out of date with respect
to one another. This also prevented the build system from trying to
regenerate locale files when I would make fixes to source code files.
> every system that I build that tree on will produce potentially
> different results, because each system could have slightly different
> versions of autoconf / automake etc installed.
That's not a terribly compelling argument; you'll also get different
results if you have (a) a different version of gcc, (b) a different
version of any library the package depends on, or (c) an optional but
compiled-in-by-default-if-found dependency installed on one system but
not another. If you want consistent results, you need a consistent
build environment.
In my case, the issue was more that the build would frequently fail
because the source code was not compatible with the version of autotools
installed on the build host.
> File metadata is as important to many developers as file contents. If I was
> a developer using rcs,cvs, sccs, pvcs, clearcase or Perforce, which can all
> keep track of timestamps
It is disingenuous to say that RCS or CVS can keep track of timestamps,
for two reasons:
1. They record only one time per file version. By default, this is
the time at which you commit the file. If you untar an autoconf-using
software release, import it into CVS, and then check it out, you will
get exactly the same autotools issue as you describe in your use case.
If you import the source tree using the -d option then you have
discarded the ability to use your repository's date history; a checkout
of the repository as of "yesterday" will falsely include most or all of
the source code you imported, even though it wasn't in your repository
at that time. Moreover, RCS doesn't even have an "import -d" analog.
2. Although a CVS initial checkout will use the timestamp recorded in
the repository for the most recent rev (normally the commit time,
possibly not if you use import -d), files changed by "cvs update" will
always have the current timestamp. So even if you used import -d, only
the initial checkout of an autotools-using software project will build
as you desire; if you update your working copy the next day and try to
build it, it may fail due to timestamp issues.
I can't speak to the other revision control systems, but since the
statement is not true of RCS or CVS I wouldn't trust that it's true of
the others.
All that said, I'm not necessarily opposed to Subversion recording mod
times. I just think you're fudging a bit in these arguments for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2008-07-18 at 07:21 -0700, Kean Johnston wrote:
> automake injects rules into the Makefile.in files that will cause it
> to re-run the autoconf/automake/libtoolize programs if it detects that
> configure.ac is more modern than configure, or if a Makefile.am is more
> modern than its corresponding Makefile.in.
I've run into this case myself, with CVS.
My workaround was to, while preparing checked out sources for build,
force all of the file timestamps to the current time, which prevents
make from deciding that any of the sources are out of date with respect
to one another. This also prevented the build system from trying to
regenerate locale files when I would make fixes to source code files.
> every system that I build that tree on will produce potentially
> different results, because each system could have slightly different
> versions of autoconf / automake etc installed.
That's not a terribly compelling argument; you'll also get different
results if you have (a) a different version of gcc, (b) a different
version of any library the package depends on, or (c) an optional but
compiled-in-by-default-if-found dependency installed on one system but
not another. If you want consistent results, you need a consistent
build environment.
In my case, the issue was more that the build would frequently fail
because the source code was not compatible with the version of autotools
installed on the build host.
> File metadata is as important to many developers as file contents. If I was
> a developer using rcs,cvs, sccs, pvcs, clearcase or Perforce, which can all
> keep track of timestamps
It is disingenuous to say that RCS or CVS can keep track of timestamps,
for two reasons:
1. They record only one time per file version. By default, this is
the time at which you commit the file. If you untar an autoconf-using
software release, import it into CVS, and then check it out, you will
get exactly the same autotools issue as you describe in your use case.
If you import the source tree using the -d option then you have
discarded the ability to use your repository's date history; a checkout
of the repository as of "yesterday" will falsely include most or all of
the source code you imported, even though it wasn't in your repository
at that time. Moreover, RCS doesn't even have an "import -d" analog.
2. Although a CVS initial checkout will use the timestamp recorded in
the repository for the most recent rev (normally the commit time,
possibly not if you use import -d), files changed by "cvs update" will
always have the current timestamp. So even if you used import -d, only
the initial checkout of an autotools-using software project will build
as you desire; if you update your working copy the next day and try to
build it, it may fail due to timestamp issues.
I can't speak to the other revision control systems, but since the
statement is not true of RCS or CVS I wouldn't trust that it's true of
the others.
All that said, I'm not necessarily opposed to Subversion recording mod
times. I just think you're fudging a bit in these arguments for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Kean Johnston <ke...@armory.com>.
> * Version control is typically used for code. 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.
...
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
We had a discussion about this in IRC a few weeks back. I said I'd outline
two usage cases where the svn approach falls down in mail, so here it is.
First, while revision control is about code, its not always about code
*that you author*. Many companies, like the one you work for, have large
parts of their source trees coming from external vendors. In the case where
that vendor source is open source software that uses autoconf and automake,
the filestamp thing is a real issue (in either normal or use-commit-times
case). automake injects rules into the Makefile.in files that will cause it
to re-run the autoconf/automake/libtoolize programs if it detects that
configure.ac is more modern than configure, or if a Makefile.am is more
modern than its corresponding Makefile.in. Thus, if I check in (for
example) a copy of the gcc tree exactly as it was in a release tarball,
every system that I build that tree on will produce potentially different
results, because each system could have slightly different versions of
autoconf / automake etc installed. This makes reproducing exact replicas of
builds all but impossible.
Second, even though my source code may live in a revision control system, I
work with that source code in a filesystem. I would expect normal
filesystem tools like find to work correctly and give me meaningful
results. With the svn approach, I cannot rely on things like "find . -newer
foo.c" and have it return anything meaningful. While I may be able to
extract similar information from svn, I shouldn't be forced to.
File metadata is as important to many developers as file contents. If I was
a developer using rcs,cvs, sccs, pvcs, clearcase or Perforce, which can all
keep track of timestamps, I would find the lack of timestamp support a
prohibiting factor in chosing svn as a replacement. At the very least, if I
had any sort of build process that kept track of things using filesystem
data, I would be hampered by svn and may have to do a lot of work to
replicate that data. While the "some other SCM does it this way" argument
never seems to sway anyone on the SVN team, perhaps the "ALL other SCM's do
it this way" argument will.
Other mails in this thread pointed in the direction of a "metadata" branch.
I would strongly urge you to consider making this, or something like it,
the default. From my own personal experience, in two companies now, I have
not been able to move to svn due to exactly this issue.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Subversion Problem - How to save file modify time?
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Folker Schamel [mailto:schamel23@spinor.com]
> Sent: Saturday, July 12, 2008 5:31 AM
> To: Anders J. Munch
> Cc: users@subversion.tigris.org; dev@subversion.tigris.org
> Subject: Re: Subversion Problem - How to save file modify time?
>
>
> Btw, for build systems of larger software, checksums are no option
> because they are far too slow. Thats the reason why for example
> also scons can use timestamps.
>
Except that builds normally do not want to preserve timestamps. Plus,
in larger software builds, you normally have a rigidly controlled
environment, formal processes and automation, so you wouldn't need
checksums even if they were fast enough. (You would probably do
scheduled audits using checksums to verify that cosmic rays haven't
flipped a bit somewhere.)
Personally, I would like the ability to preserve original file
timestamps, but I can't formulate any business justification for doing
so that cannot be solved with more reliable processes such as auditing
or checksum aware deployment scripts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion Problem - How to save file modify time?
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Folker Schamel [mailto:schamel23@spinor.com]
> Sent: Saturday, July 12, 2008 5:31 AM
> To: Anders J. Munch
> Cc: users@subversion.tigris.org; dev@subversion.tigris.org
> Subject: Re: Subversion Problem - How to save file modify time?
>
>
> Btw, for build systems of larger software, checksums are no option
> because they are far too slow. Thats the reason why for example
> also scons can use timestamps.
>
Except that builds normally do not want to preserve timestamps. Plus,
in larger software builds, you normally have a rigidly controlled
environment, formal processes and automation, so you wouldn't need
checksums even if they were fast enough. (You would probably do
scheduled audits using checksums to verify that cosmic rays haven't
flipped a bit somewhere.)
Personally, I would like the ability to preserve original file
timestamps, but I can't formulate any business justification for doing
so that cannot be solved with more reliable processes such as auditing
or checksum aware deployment scripts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Anders J. Munch wrote:
> Les Mikesell wrote:
>> If you are on a unix-like filesystem, you just use a
>> different timestamp
>> for each purpose. mtime is for the last modification of the file
>> contents, ctime for inode changes like moves or ownership/permission
>> changes. Normally ctime can't be set by the user and can never be
>> earlier than mtime (because an update of mtime is an inode change that
>> triggers an update to ctime). Thus there is no doubt about what mtime
>> is supposed to mean, just a choice of which timestamp to observe for
>> your purpose.
>
> And if you copy a file from one file system to another, what then? I
> was under the impression from earlier discussion that Linux file
> managers would create new files with new mtimes on copying, at least
> in some circumstances?
Many (most?) unix-aware copying methods (tar, zip, rsync, gnu cp, etc.)
offer ways to preserve mtimes. I'm not sure what each GUI file manager
does but why use one limited or broken mechanism to excuse another?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Anders J. Munch wrote:
> Les Mikesell wrote:
>> If you are on a unix-like filesystem, you just use a
>> different timestamp
>> for each purpose. mtime is for the last modification of the file
>> contents, ctime for inode changes like moves or ownership/permission
>> changes. Normally ctime can't be set by the user and can never be
>> earlier than mtime (because an update of mtime is an inode change that
>> triggers an update to ctime). Thus there is no doubt about what mtime
>> is supposed to mean, just a choice of which timestamp to observe for
>> your purpose.
>
> And if you copy a file from one file system to another, what then? I
> was under the impression from earlier discussion that Linux file
> managers would create new files with new mtimes on copying, at least
> in some circumstances?
Many (most?) unix-aware copying methods (tar, zip, rsync, gnu cp, etc.)
offer ways to preserve mtimes. I'm not sure what each GUI file manager
does but why use one limited or broken mechanism to excuse another?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Les Mikesell wrote:
> If you are on a unix-like filesystem, you just use a
> different timestamp
> for each purpose. mtime is for the last modification of the file
> contents, ctime for inode changes like moves or ownership/permission
> changes. Normally ctime can't be set by the user and can never be
> earlier than mtime (because an update of mtime is an inode change that
> triggers an update to ctime). Thus there is no doubt about what mtime
> is supposed to mean, just a choice of which timestamp to observe for
> your purpose.
And if you copy a file from one file system to another, what then? I
was under the impression from earlier discussion that Linux file
managers would create new files with new mtimes on copying, at least
in some circumstances?
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Les Mikesell wrote:
> If you are on a unix-like filesystem, you just use a
> different timestamp
> for each purpose. mtime is for the last modification of the file
> contents, ctime for inode changes like moves or ownership/permission
> changes. Normally ctime can't be set by the user and can never be
> earlier than mtime (because an update of mtime is an inode change that
> triggers an update to ctime). Thus there is no doubt about what mtime
> is supposed to mean, just a choice of which timestamp to observe for
> your purpose.
And if you copy a file from one file system to another, what then? I
was under the impression from earlier discussion that Linux file
managers would create new files with new mtimes on copying, at least
in some circumstances?
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Anders J. Munch wrote:
>
>>> The "make argument" is flawed. Read my 2008-06-10 posting
>>> http://article.gmane.org/gmane.comp.version-control.subversion
>> .user/77803
>>
>> Sorry, this makes no sense. The whole idea of the last modified
>> timestamp is that it represents the time when this file was
>> last modified.
>
> Everyone agrees on that. The point of contention is whether moving
> identical file contents from one place to another constitutes
> modification.
>
> Or should I say, there are two different traditions, one that says it
> does, one that says it doesn't. Neither tradition is more right than
> the other, they are just different. And those who see a file as
> something that can be moved without changing it, would like to see
> Subversion support their tradition better.
If you are on a unix-like filesystem, you just use a different timestamp
for each purpose. mtime is for the last modification of the file
contents, ctime for inode changes like moves or ownership/permission
changes. Normally ctime can't be set by the user and can never be
earlier than mtime (because an update of mtime is an inode change that
triggers an update to ctime). Thus there is no doubt about what mtime
is supposed to mean, just a choice of which timestamp to observe for
your purpose.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Les Mikesell <le...@gmail.com>.
Anders J. Munch wrote:
>
>>> The "make argument" is flawed. Read my 2008-06-10 posting
>>> http://article.gmane.org/gmane.comp.version-control.subversion
>> .user/77803
>>
>> Sorry, this makes no sense. The whole idea of the last modified
>> timestamp is that it represents the time when this file was
>> last modified.
>
> Everyone agrees on that. The point of contention is whether moving
> identical file contents from one place to another constitutes
> modification.
>
> Or should I say, there are two different traditions, one that says it
> does, one that says it doesn't. Neither tradition is more right than
> the other, they are just different. And those who see a file as
> something that can be moved without changing it, would like to see
> Subversion support their tradition better.
If you are on a unix-like filesystem, you just use a different timestamp
for each purpose. mtime is for the last modification of the file
contents, ctime for inode changes like moves or ownership/permission
changes. Normally ctime can't be set by the user and can never be
earlier than mtime (because an update of mtime is an inode change that
triggers an update to ctime). Thus there is no doubt about what mtime
is supposed to mean, just a choice of which timestamp to observe for
your purpose.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Folker Schamel wrote:
> Anders J. Munch:
> > The "make argument" is flawed. Read my 2008-06-10 posting
> > http://article.gmane.org/gmane.comp.version-control.subversion
> .user/77803
>
> Sorry, this makes no sense. The whole idea of the last modified
> timestamp is that it represents the time when this file was
> last modified.
Everyone agrees on that. The point of contention is whether moving
identical file contents from one place to another constitutes
modification.
Or should I say, there are two different traditions, one that says it
does, one that says it doesn't. Neither tradition is more right than
the other, they are just different. And those who see a file as
something that can be moved without changing it, would like to see
Subversion support their tradition better.
> Btw, for build systems of larger software, checksums are no option
> because they are far too slow. Thats the reason why for example
> also scons can use timestamps.
A build system that detects timestamp /change/ does not inherit make's
deficiencies.
The source of make's weaknesses is that it doesn't have its own
database, but relies solely on information that just happens to be
already available in the file system. A build system with memory can
outperform make both on speed and accuracy.
But that's a digression. My key point is this: if you use make, then
make /is/ going to fail you from time to time, and if you don't have
some strategy for coping with that, like say a forced full rebuild
before any release, then you're already in trouble.
It's time to let go of the myth that /usr/bin/make is some sort of
authoritative source on how to deal with timestamps.
regards,
Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Folker Schamel wrote:
> Anders J. Munch:
> > The "make argument" is flawed. Read my 2008-06-10 posting
> > http://article.gmane.org/gmane.comp.version-control.subversion
> .user/77803
>
> Sorry, this makes no sense. The whole idea of the last modified
> timestamp is that it represents the time when this file was
> last modified.
Everyone agrees on that. The point of contention is whether moving
identical file contents from one place to another constitutes
modification.
Or should I say, there are two different traditions, one that says it
does, one that says it doesn't. Neither tradition is more right than
the other, they are just different. And those who see a file as
something that can be moved without changing it, would like to see
Subversion support their tradition better.
> Btw, for build systems of larger software, checksums are no option
> because they are far too slow. Thats the reason why for example
> also scons can use timestamps.
A build system that detects timestamp /change/ does not inherit make's
deficiencies.
The source of make's weaknesses is that it doesn't have its own
database, but relies solely on information that just happens to be
already available in the file system. A build system with memory can
outperform make both on speed and accuracy.
But that's a digression. My key point is this: if you use make, then
make /is/ going to fail you from time to time, and if you don't have
some strategy for coping with that, like say a forced full rebuild
before any release, then you're already in trouble.
It's time to let go of the myth that /usr/bin/make is some sort of
authoritative source on how to deal with timestamps.
regards,
Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Folker Schamel <sc...@spinor.com>.
Anders J. Munch wrote:
> sussman@gmail.com 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, [...]
>
> I sincerely doubt it's any sort of minority, let alone a very small one.
>
>> * Version control is typically used for code. 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.
>
> The "make argument" is flawed. Read my 2008-06-10 posting
> http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
Sorry, this makes no sense. The whole idea of the last modified
timestamp is that it represents the time when this file was
last modified.
A lot of software is based on that convention, not only make.
Therefore, also svn should (at least in its default configuration)
follow that convention and touch the timestamp if it modifies
a file for example by svn update.
This is the only correct behavior (not disputing that other behaviors
may be useful as workaround in untypical situations).
Btw, for build systems of larger software, checksums are no option
because they are far too slow. Thats the reason why for example
also scons can use timestamps.
Folker
>
> regards, Anders
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Folker Schamel <sc...@spinor.com>.
Anders J. Munch wrote:
> sussman@gmail.com 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, [...]
>
> I sincerely doubt it's any sort of minority, let alone a very small one.
>
>> * Version control is typically used for code. 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.
>
> The "make argument" is flawed. Read my 2008-06-10 posting
> http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
Sorry, this makes no sense. The whole idea of the last modified
timestamp is that it represents the time when this file was
last modified.
A lot of software is based on that convention, not only make.
Therefore, also svn should (at least in its default configuration)
follow that convention and touch the timestamp if it modifies
a file for example by svn update.
This is the only correct behavior (not disputing that other behaviors
may be useful as workaround in untypical situations).
Btw, for build systems of larger software, checksums are no option
because they are far too slow. Thats the reason why for example
also scons can use timestamps.
Folker
>
> regards, Anders
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Talden <ta...@gmail.com>.
>>> Therefore, also svn should (at least in its default configuration)
>>> follow that convention and touch the timestamp if it modifies
>>> a file for example by svn update.
>>
>> No. If I'm going back to an earlier revision of a source file (when
>> bisecting, for instance), I expect "make" to rebuild everything
>> depending on that file - because in my working copy, that file was
>> changed *by svn*. The user, and Make, live in real time, which is
>> monotonically increasing - not in subversion time which can be
>> spun back and forth like magnetic tape.
>
> I think we both mean exactly the same:
> svn should behave (as default) as it behaves now:
> "svn update" sets the file time to the current time (touch).
And yet many users enable the commit-times feature, thumbing their
nose at this use-case. Storing modification times is useful in
use-cases of a non-trivial number of users. If someone produces a
patch that supports this, the working copy code should continue to
support the current modes of operation (and keep the same default
behaviour) to avoid alienating existing users.
I think everyone's done arguing for and against the feature - some
find it useful some do not - we get it already.
Stick to the arguments that make sense (pretty much every word of Karl
Fogel recent post). This is an open project, if someone does the
work, the results do not harm existing users and the patches meet the
required standard then accept them into the product. As always no-one
is compelled to write it, volunteers welcome.
Note that a similar fight has been underway practically forever for an
obliterate feature as well and only somewhat recently has this really
been accepted as not something needing pitchforks with an angry mob
(or is it angry mob with pitchforks - is it the users or the tool that
drives things, I forget) to protect Subversion from the feature. I
mean ok, progress seems to have stalled a little, but at least the
attitude has changed to a desire to see a good design.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Folker Schamel <sc...@spinor.com>.
Mattias Engdegård wrote:
> Folker Schamel <sc...@spinor.com> writes:
>
>> Therefore, also svn should (at least in its default configuration)
>> follow that convention and touch the timestamp if it modifies
>> a file for example by svn update.
>
> No. If I'm going back to an earlier revision of a source file (when
> bisecting, for instance), I expect "make" to rebuild everything
> depending on that file - because in my working copy, that file was
> changed *by svn*. The user, and Make, live in real time, which is
> monotonically increasing - not in subversion time which can be
> spun back and forth like magnetic tape.
I think we both mean exactly the same:
svn should behave (as default) as it behaves now:
"svn update" sets the file time to the current time (touch).
>
> It's just like ordinary time machines. If travelling backwards in time
> would make you younger, you could never go back and kill Hitler.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Mattias Engdegård <ma...@virtutech.se>.
Folker Schamel <sc...@spinor.com> writes:
>Therefore, also svn should (at least in its default configuration)
>follow that convention and touch the timestamp if it modifies
>a file for example by svn update.
No. If I'm going back to an earlier revision of a source file (when
bisecting, for instance), I expect "make" to rebuild everything
depending on that file - because in my working copy, that file was
changed *by svn*. The user, and Make, live in real time, which is
monotonically increasing - not in subversion time which can be
spun back and forth like magnetic tape.
It's just like ordinary time machines. If travelling backwards in time
would make you younger, you could never go back and kill Hitler.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
sussman@gmail.com 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, [...]
I sincerely doubt it's any sort of minority, let alone a very small one.
> * Version control is typically used for code. 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.
The "make argument" is flawed. Read my 2008-06-10 posting
http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
regards, Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
sussman@gmail.com 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, [...]
I sincerely doubt it's any sort of minority, let alone a very small one.
> * Version control is typically used for code. 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.
The "make argument" is flawed. Read my 2008-06-10 posting
http://article.gmane.org/gmane.comp.version-control.subversion.user/77803
regards, Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Julian Foad <ju...@btopenworld.com>.
Ben,
This is a pretty well written answer to a Frequently Asked Question that
doesn't seem to be in <faq.html>. Fancy putting it there?
- Julian
On Thu, 2008-07-10 at 21:43 -0500, 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:
>
> * 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.
>
> * Version control is typically used for code. 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.
>
> * 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.
>
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
>
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
>
>
>
>
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Mr. Unterberg,
> >
> >
> > Yes , I see that subversion support good functions but based on lost
> > file modify date. Is it?
> >
> > I like subversion client very much. But as an end user, we can't select
> > a version control system which can't save file modify date. Because this is
> > very important for our team-work in software developement progress. It's so
> > sorry.
> >
> > I think that you can get better idea yourself to shot the problem
> > later. Perhaps other version control system could be your referrence. If
> > this problem is ok, contract me as soon as you can please. We'll select
> > subversion as our version control system.
> >
> > Thanks & Best Regards,
> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> > Addr: 上海市平江路15号（zip:200050）
> > Tel(O): 86-21-64031580 x 2512
> > Tel(MB): 13916313249
> >
> > ----- Original Message -----
> > From: "Norbert Unterberg" <nu...@gmail.com>
> > To: "郭煜" <gu...@dscomm.com.cn>
> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> > Sent: Friday, July 11, 2008 5:06 AM
> > Subject: Re: Subversion Problem - How to save file modify time?
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Invendor,
> >> >
> >> > This is a software company in china. I'm an engineer at
> >> > develope-management department.
> >> >
> >> > We used other version control system as perforce or starteam before.
> >> > Now we are trying subversion.
> >> >
> >> > During trying subversion, we find that file modify time could not be
> >> > saved into subversion and get from subversion.
> >> >
> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> > problem. How to shot it, if a deploy problem.
> >> >
> >>
> >> There is a configuration option "use-commit-times" which you can find
> >> in the documentation, It does not preserve the real file modify time
> >> but the commit time which might be good enough.
> >> However, for software development, the default behaviour (file time is
> >> the time of last update or checkout) usually works best.
> >>
> >> The problem with preserving file modify time is that it is very hard
> >> to do right. What is the correct modify time if two people change the
> >> same file and then they commit/update/merge the data? What to do when
> >> merging a branch? IF SVN modifies the file contents during a commit
> >> (see svn:keyword property) does that count as a file modification or
> >> not?
> >>
> >> Norbert
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Furter,
Yes, it's a good idea. I have suggested it to our coding managers and coding engineers. But they can not accept for our great source files and many outside debugging without version control system supported at user's locale.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2503
Tel(MB): 13916313249
----- Original Message -----
From: "Martin Furter" <mf...@rola.ch>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: "Ben Collins-Sussman" <su...@red-bean.com>; "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Monday, July 14, 2008 4:13 AM
Subject: Re: Subversion Problem - How to save file modify time?
On Fri, 11 Jul 2008, [gb2312] 郭煜 wrote:
>
> Dear Mr. Collins-Sussman,
>
>
> We used other version control system before. If using subversion was
> sured, we should move all files form old version control system to
> subversion. These files include source files and destination files and
> even other many invendors' source files and destination files. But,
> subversion will lost their modify time all. Oh... Some of our
> files maybe fifteen years old. A lot of our coding engineers are new.
> Our coding managers feels difficulty to manage the great source and
> tech-support the destination file without file modify time.
>
> Of course I think subversion developement team is the most specially on
> version control system. Also of course the coding habit is belong to
> coding engineers and coding managers. So we have to support the habit
> belong to them.
>
> It's so sorry. But we wish that this problem will be shot soon. Says
> again, I like subversion client very much truely.
>
> By the way, why could not you save the commit time to file create time
> and save the the last changed time to file modify time? Usually, in
> operation system, file create time is not really and not very useful.
> Why don't you use it?
>
I guess a possible solution to your problem would be to write a
script which imports your tree and groups files with the same modification
date into a revision with that date. That way you can just look at the log
of a file to see when it last changed.
I could help you with such a script if you like this idea.
Martin
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Furter,
Yes, it's a good idea. I have suggested it to our coding managers and coding engineers. But they can not accept for our great source files and many outside debugging without version control system supported at user's locale.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2503
Tel(MB): 13916313249
----- Original Message -----
From: "Martin Furter" <mf...@rola.ch>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: "Ben Collins-Sussman" <su...@red-bean.com>; "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Monday, July 14, 2008 4:13 AM
Subject: Re: Subversion Problem - How to save file modify time?
On Fri, 11 Jul 2008, [gb2312] 郭煜 wrote:
>
> Dear Mr. Collins-Sussman,
>
>
> We used other version control system before. If using subversion was
> sured, we should move all files form old version control system to
> subversion. These files include source files and destination files and
> even other many invendors' source files and destination files. But,
> subversion will lost their modify time all. Oh... Some of our
> files maybe fifteen years old. A lot of our coding engineers are new.
> Our coding managers feels difficulty to manage the great source and
> tech-support the destination file without file modify time.
>
> Of course I think subversion developement team is the most specially on
> version control system. Also of course the coding habit is belong to
> coding engineers and coding managers. So we have to support the habit
> belong to them.
>
> It's so sorry. But we wish that this problem will be shot soon. Says
> again, I like subversion client very much truely.
>
> By the way, why could not you save the commit time to file create time
> and save the the last changed time to file modify time? Usually, in
> operation system, file create time is not really and not very useful.
> Why don't you use it?
>
I guess a possible solution to your problem would be to write a
script which imports your tree and groups files with the same modification
date into a revision with that date. That way you can just look at the log
of a file to see when it last changed.
I could help you with such a script if you like this idea.
Martin
Re: Subversion Problem - How to save file modify time?
Posted by Martin Furter <mf...@rola.ch>.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by Martin Furter <mf...@rola.ch>.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Collins-Sussman,
We used other version control system before. If using subversion was sured, we should move all files form old version control system to subversion. These files include source files and destination files and even other many invendors' source files and destination files. But, subversion will lost their modify time all. Oh... Some of our files maybe fifteen years old. A lot of our coding engineers are new. Our coding managers feels difficulty to manage the great source and tech-support the destination file without file modify time.
Of course I think subversion developement team is the most specially on version control system. Also of course the coding habit is belong to coding engineers and coding managers. So we have to support the habit belong to them.
It's so sorry. But we wish that this problem will be shot soon. Says again, I like subversion client very much truely.
By the way, why could not you save the commit time to file create time and save the the last changed time to file modify time? Usually, in operation system, file create time is not really and not very useful. Why don't you use it?
Best Regards,
Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2512
Tel(MB): 13916313249
----- Original Message -----
From: "Ben Collins-Sussman" <su...@red-bean.com>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Friday, July 11, 2008 10:43 AM
Subject: Re: Subversion Problem - How to save file modify time?
> 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:
>
> * 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.
>
> * Version control is typically used for code. 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.
>
> * 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.
>
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
>
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
>
>
>
>
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Mr. Unterberg,
> >
> >
> > Yes , I see that subversion support good functions but based on lost
> > file modify date. Is it?
> >
> > I like subversion client very much. But as an end user, we can't select
> > a version control system which can't save file modify date. Because this is
> > very important for our team-work in software developement progress. It's so
> > sorry.
> >
> > I think that you can get better idea yourself to shot the problem
> > later. Perhaps other version control system could be your referrence. If
> > this problem is ok, contract me as soon as you can please. We'll select
> > subversion as our version control system.
> >
> > Thanks & Best Regards,
> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> > Addr: 上海市平江路15号（zip:200050）
> > Tel(O): 86-21-64031580 x 2512
> > Tel(MB): 13916313249
> >
> > ----- Original Message -----
> > From: "Norbert Unterberg" <nu...@gmail.com>
> > To: "郭煜" <gu...@dscomm.com.cn>
> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> > Sent: Friday, July 11, 2008 5:06 AM
> > Subject: Re: Subversion Problem - How to save file modify time?
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Invendor,
> >> >
> >> > This is a software company in china. I'm an engineer at
> >> > develope-management department.
> >> >
> >> > We used other version control system as perforce or starteam before.
> >> > Now we are trying subversion.
> >> >
> >> > During trying subversion, we find that file modify time could not be
> >> > saved into subversion and get from subversion.
> >> >
> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> > problem. How to shot it, if a deploy problem.
> >> >
> >>
> >> There is a configuration option "use-commit-times" which you can find
> >> in the documentation, It does not preserve the real file modify time
> >> but the commit time which might be good enough.
> >> However, for software development, the default behaviour (file time is
> >> the time of last update or checkout) usually works best.
> >>
> >> The problem with preserving file modify time is that it is very hard
> >> to do right. What is the correct modify time if two people change the
> >> same file and then they commit/update/merge the data? What to do when
> >> merging a branch? IF SVN modifies the file contents during a commit
> >> (see svn:keyword property) does that count as a file modification or
> >> not?
> >>
> >> Norbert
> >>
>
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Collins-Sussman,
We used other version control system before. If using subversion was sured, we should move all files form old version control system to subversion. These files include source files and destination files and even other many invendors' source files and destination files. But, subversion will lost their modify time all. Oh... Some of our files maybe fifteen years old. A lot of our coding engineers are new. Our coding managers feels difficulty to manage the great source and tech-support the destination file without file modify time.
Of course I think subversion developement team is the most specially on version control system. Also of course the coding habit is belong to coding engineers and coding managers. So we have to support the habit belong to them.
It's so sorry. But we wish that this problem will be shot soon. Says again, I like subversion client very much truely.
By the way, why could not you save the commit time to file create time and save the the last changed time to file modify time? Usually, in operation system, file create time is not really and not very useful. Why don't you use it?
Best Regards,
Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2512
Tel(MB): 13916313249
----- Original Message -----
From: "Ben Collins-Sussman" <su...@red-bean.com>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: "Norbert Unterberg" <nu...@gmail.com>; <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Friday, July 11, 2008 10:43 AM
Subject: Re: Subversion Problem - How to save file modify time?
> 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:
>
> * 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.
>
> * Version control is typically used for code. 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.
>
> * 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.
>
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
>
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
>
>
>
>
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Mr. Unterberg,
> >
> >
> > Yes , I see that subversion support good functions but based on lost
> > file modify date. Is it?
> >
> > I like subversion client very much. But as an end user, we can't select
> > a version control system which can't save file modify date. Because this is
> > very important for our team-work in software developement progress. It's so
> > sorry.
> >
> > I think that you can get better idea yourself to shot the problem
> > later. Perhaps other version control system could be your referrence. If
> > this problem is ok, contract me as soon as you can please. We'll select
> > subversion as our version control system.
> >
> > Thanks & Best Regards,
> > Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> > Addr: 上海市平江路15号（zip:200050）
> > Tel(O): 86-21-64031580 x 2512
> > Tel(MB): 13916313249
> >
> > ----- Original Message -----
> > From: "Norbert Unterberg" <nu...@gmail.com>
> > To: "郭煜" <gu...@dscomm.com.cn>
> > Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> > Sent: Friday, July 11, 2008 5:06 AM
> > Subject: Re: Subversion Problem - How to save file modify time?
> >> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> >> > Dear Invendor,
> >> >
> >> > This is a software company in china. I'm an engineer at
> >> > develope-management department.
> >> >
> >> > We used other version control system as perforce or starteam before.
> >> > Now we are trying subversion.
> >> >
> >> > During trying subversion, we find that file modify time could not be
> >> > saved into subversion and get from subversion.
> >> >
> >> > Is it a design problem or deploy problem ? I hope it's a deploy
> >> > problem. How to shot it, if a deploy problem.
> >> >
> >>
> >> There is a configuration option "use-commit-times" which you can find
> >> in the documentation, It does not preserve the real file modify time
> >> but the commit time which might be good enough.
> >> However, for software development, the default behaviour (file time is
> >> the time of last update or checkout) usually works best.
> >>
> >> The problem with preserving file modify time is that it is very hard
> >> to do right. What is the correct modify time if two people change the
> >> same file and then they commit/update/merge the data? What to do when
> >> merging a branch? IF SVN modifies the file contents during a commit
> >> (see svn:keyword property) does that count as a file modification or
> >> not?
> >>
> >> Norbert
> >>
>
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
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:
* 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.
* Version control is typically used for code. 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.
* 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.
* If you want to be even friendlier to people without subversion, you
can put $LastChangedDate$ or $Revision$ keywords directly into the
files to be expanded.
If none of these features satisifes your use-case, I'm curious to hear
exactly what you're trying to accomplish, and why these solutions
don't work for you.
2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> Dear Mr. Unterberg,
>
>
> Yes , I see that subversion support good functions but based on lost
> file modify date. Is it?
>
> I like subversion client very much. But as an end user, we can't select
> a version control system which can't save file modify date. Because this is
> very important for our team-work in software developement progress. It's so
> sorry.
>
> I think that you can get better idea yourself to shot the problem
> later. Perhaps other version control system could be your referrence. If
> this problem is ok, contract me as soon as you can please. We'll select
> subversion as our version control system.
>
> Thanks & Best Regards,
> Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> Addr: 上海市平江路15号（zip:200050）
> Tel(O): 86-21-64031580 x 2512
> Tel(MB): 13916313249
>
> ----- Original Message -----
> From: "Norbert Unterberg" <nu...@gmail.com>
> To: "郭煜" <gu...@dscomm.com.cn>
> Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> Sent: Friday, July 11, 2008 5:06 AM
> Subject: Re: Subversion Problem - How to save file modify time?
>> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> > Dear Invendor,
>> >
>> > This is a software company in china. I'm an engineer at
>> > develope-management department.
>> >
>> > We used other version control system as perforce or starteam before.
>> > Now we are trying subversion.
>> >
>> > During trying subversion, we find that file modify time could not be
>> > saved into subversion and get from subversion.
>> >
>> > Is it a design problem or deploy problem ? I hope it's a deploy
>> > problem. How to shot it, if a deploy problem.
>> >
>>
>> There is a configuration option "use-commit-times" which you can find
>> in the documentation, It does not preserve the real file modify time
>> but the commit time which might be good enough.
>> However, for software development, the default behaviour (file time is
>> the time of last update or checkout) usually works best.
>>
>> The problem with preserving file modify time is that it is very hard
>> to do right. What is the correct modify time if two people change the
>> same file and then they commit/update/merge the data? What to do when
>> merging a branch? IF SVN modifies the file contents during a commit
>> (see svn:keyword property) does that count as a file modification or
>> not?
>>
>> Norbert
>>
Re: Subversion Problem - How to save file modify time?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
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:
* 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.
* Version control is typically used for code. 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.
* 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.
* If you want to be even friendlier to people without subversion, you
can put $LastChangedDate$ or $Revision$ keywords directly into the
files to be expanded.
If none of these features satisifes your use-case, I'm curious to hear
exactly what you're trying to accomplish, and why these solutions
don't work for you.
2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> Dear Mr. Unterberg,
>
>
> Yes , I see that subversion support good functions but based on lost
> file modify date. Is it?
>
> I like subversion client very much. But as an end user, we can't select
> a version control system which can't save file modify date. Because this is
> very important for our team-work in software developement progress. It's so
> sorry.
>
> I think that you can get better idea yourself to shot the problem
> later. Perhaps other version control system could be your referrence. If
> this problem is ok, contract me as soon as you can please. We'll select
> subversion as our version control system.
>
> Thanks & Best Regards,
> Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> Addr: 上海市平江路15号（zip:200050）
> Tel(O): 86-21-64031580 x 2512
> Tel(MB): 13916313249
>
> ----- Original Message -----
> From: "Norbert Unterberg" <nu...@gmail.com>
> To: "郭煜" <gu...@dscomm.com.cn>
> Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
> Sent: Friday, July 11, 2008 5:06 AM
> Subject: Re: Subversion Problem - How to save file modify time?
>> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
>> > Dear Invendor,
>> >
>> > This is a software company in china. I'm an engineer at
>> > develope-management department.
>> >
>> > We used other version control system as perforce or starteam before.
>> > Now we are trying subversion.
>> >
>> > During trying subversion, we find that file modify time could not be
>> > saved into subversion and get from subversion.
>> >
>> > Is it a design problem or deploy problem ? I hope it's a deploy
>> > problem. How to shot it, if a deploy problem.
>> >
>>
>> There is a configuration option "use-commit-times" which you can find
>> in the documentation, It does not preserve the real file modify time
>> but the commit time which might be good enough.
>> However, for software development, the default behaviour (file time is
>> the time of last update or checkout) usually works best.
>>
>> The problem with preserving file modify time is that it is very hard
>> to do right. What is the correct modify time if two people change the
>> same file and then they commit/update/merge the data? What to do when
>> merging a branch? IF SVN modifies the file contents during a commit
>> (see svn:keyword property) does that count as a file modification or
>> not?
>>
>> Norbert
>>
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Unterberg,
Yes , I see that subversion support good functions but based on lost file modify date. Is it?
I like subversion client very much. But as an end user, we can't select a version control system which can't save file modify date. Because this is very important for our team-work in software developement progress. It's so sorry.
I think that you can get better idea yourself to shot the problem later. Perhaps other version control system could be your referrence. If this problem is ok, contract me as soon as you can please. We'll select subversion as our version control system.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2512
Tel(MB): 13916313249
----- Original Message -----
From: "Norbert Unterberg" <nu...@gmail.com>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Friday, July 11, 2008 5:06 AM
Subject: Re: Subversion Problem - How to save file modify time?
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Invendor,
> >
> > This is a software company in china. I'm an engineer at
> > develope-management department.
> >
> > We used other version control system as perforce or starteam before.
> > Now we are trying subversion.
> >
> > During trying subversion, we find that file modify time could not be
> > saved into subversion and get from subversion.
> >
> > Is it a design problem or deploy problem ? I hope it's a deploy
> > problem. How to shot it, if a deploy problem.
> >
>
> There is a configuration option "use-commit-times" which you can find
> in the documentation, It does not preserve the real file modify time
> but the commit time which might be good enough.
> However, for software development, the default behaviour (file time is
> the time of last update or checkout) usually works best.
>
> The problem with preserving file modify time is that it is very hard
> to do right. What is the correct modify time if two people change the
> same file and then they commit/update/merge the data? What to do when
> merging a branch? IF SVN modifies the file contents during a commit
> (see svn:keyword property) does that count as a file modification or
> not?
>
> Norbert
>
Re: Subversion Problem - How to save file modify time?
Posted by 郭煜 <gu...@dscomm.com.cn>.
Dear Mr. Unterberg,
Yes , I see that subversion support good functions but based on lost file modify date. Is it?
I like subversion client very much. But as an end user, we can't select a version control system which can't save file modify date. Because this is very important for our team-work in software developement progress. It's so sorry.
I think that you can get better idea yourself to shot the problem later. Perhaps other version control system could be your referrence. If this problem is ok, contract me as soon as you can please. We'll select subversion as our version control system.
Thanks & Best Regards,
Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号（zip:200050）
Tel(O): 86-21-64031580 x 2512
Tel(MB): 13916313249
----- Original Message -----
From: "Norbert Unterberg" <nu...@gmail.com>
To: "郭煜" <gu...@dscomm.com.cn>
Cc: <us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Friday, July 11, 2008 5:06 AM
Subject: Re: Subversion Problem - How to save file modify time?
> 2008/7/10 郭煜 <gu...@dscomm.com.cn>:
> > Dear Invendor,
> >
> > This is a software company in china. I'm an engineer at
> > develope-management department.
> >
> > We used other version control system as perforce or starteam before.
> > Now we are trying subversion.
> >
> > During trying subversion, we find that file modify time could not be
> > saved into subversion and get from subversion.
> >
> > Is it a design problem or deploy problem ? I hope it's a deploy
> > problem. How to shot it, if a deploy problem.
> >
>
> There is a configuration option "use-commit-times" which you can find
> in the documentation, It does not preserve the real file modify time
> but the commit time which might be good enough.
> However, for software development, the default behaviour (file time is
> the time of last update or checkout) usually works best.
>
> The problem with preserving file modify time is that it is very hard
> to do right. What is the correct modify time if two people change the
> same file and then they commit/update/merge the data? What to do when
> merging a branch? IF SVN modifies the file contents during a commit
> (see svn:keyword property) does that count as a file modification or
> not?
>
> Norbert
>