You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2003/07/08 22:35:35 UTC
Re: cvs commit: apr/test testfileinfo.c
Branko Čibej wrote:
>Ben Collins-Sussman wrote:
>
>
>
>>sussman@apache.org writes:
>>
>>
>>
>>
>>
>>>sussman 2003/07/07 15:44:11
>>>
>>> Log:
>>> New apr_file_mtime_set() API, implemented in unix and win32.
>>> Patches from Branko Cibej (brane) and Matt Kraai <kr...@alumni.cmu.edu>.
>>>
>>>
>>>
>>>
>>So can this API be renamed to apr_path_mtime_set()? Can it be made to
>>work on directories as well as files? Certainly the unix utime()
>>implementation works on any kind of inode. How about brane's win32
>>implementation?
>>
>>
>>
>I think the Win32 bit won't work on directories without changes,
>although I think it can be changed so that it does. The Unix
>implementation probably will work on dirs unchanged.
>
>I have no objection to changing the funciton name (or at least the docs)
>and teach it to work on both files and dirs.
>
>
Oh, by the way: lying about the modification time of a directory is
generally not a good idea, and it's not something "make" is interested
in. Let's think carefully about what we want to achieve here before
starting to change directory mtimes.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Jack Repenning <jr...@collab.net>.
At 7:51 AM -0500 7/9/03, Ben Collins-Sussman wrote:
>Branko âibej <br...@xbc.nu> writes:
>
>> I don't know if there's a danger, but someone (you? :-) has to think
>> about whether it's consistent. Can files in the directory have mtimes
>> newer than the directory itself?
>
>Nope, because of the bubble-up effect in the repository. For example,
>the last-commit-time of '/' is always equal to the date of the last
>commit.
Wait a bit. Is Ben answering the question Branko asked?
In the file system, directory mtimes are
typically unrelated to content mtimes. In Unix,
changing the file does not change the directory,
only creating, removing, renaming files does
that. (If you think your editor updates the
directory mtime when you change a file, you
should study "M-x apropos backup-by-copying";-).
But conversely, some of those directory-changing
operations have no effect on the file (e.g.,
renaming). So the directory might be newer or
older than its contents, and directory mtime
can't be taken to tell you anything about
content. In DOS, there's even less correlation.
In the Subversion repo, there's that bubble-up
thang, a necessary price to pay for O(1) tagging,
which means there is a very definite relationship
between directory and content mtimes.
But in the Subversion working copy, there may be
mixed revisions within a directory, and there may
be arbitrary mere filesystem operations after
Subversion imposes its will. In general, there's
no clear probability that the wc follows *any*
pattern!
I think here again, the best we can promise is
that immediately following an export or checkout,
the mtimes have some pattern. Anyone who needs
the wc mtimes to tell them something will have to
settle for having this only in ex nihilo WC's.
So hey, why not set dir mtimes to commit times in
these and these only circumstances?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Russell Yanofsky <re...@columbia.edu>.
"Branko Cibej" <br...@xbc.nu> wrote in message news:3F0C4667.1040001@xbc.nu...
> Ben Collins-Sussman wrote:
> >Nope, because of the bubble-up effect in the repository. For example,
> >the last-commit-time of '/' is always equal to the date of the last
> >commit.
> >
> Hah! But you didn't necessarily make any changes to the directory,
> right? If you want to be consistent WRT directory modification times,
> then the effects of the bubble-up must *not* be visible in the working
> copy. Bubble-up is an implementation detail.
An implementation that doens't use bubble up could give the same result.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>I don't know if there's a danger, but someone (you? :-) has to think
>>about whether it's consistent. Can files in the directory have mtimes
>>newer than the directory itself?
>>
>>
>
>Nope, because of the bubble-up effect in the repository. For example,
>the last-commit-time of '/' is always equal to the date of the last
>commit.
>
Hah! But you didn't necessarily make any changes to the directory,
right? If you want to be consistent WRT directory modification times,
then the effects of the bubble-up must *not* be visible in the working
copy. Bubble-up is an implementation detail.
See? It becomes very interesting.
>>Does a propchange on a directory affect its mtime? Etc. ad nauseam.
>>
>>
>
>Hmmmm, yeah, I guess one could commit a propchange to a directory, and
>then it would have a timestamp newer than its contents. I wonder if
>that would mess up any working copies.
>
>Maybe I'll just stay away from this problem for now.
>
>
Good boy. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Wed, Jul 09, 2003 at 07:51:59AM -0500, Ben Collins-Sussman wrote:
[snip]
> > Does a propchange on a directory affect its mtime? Etc. ad nauseam.
>
> Hmmmm, yeah, I guess one could commit a propchange to a directory, and
> then it would have a timestamp newer than its contents. I wonder if
> that would mess up any working copies.
[snip]
There's nothing wrong with having a directory that's got a newer
timestamp than any of the files it contains:
$ mkdir test
$ cd test
$ touch something
$ ls -al
total 6
drwxr-xr-x 2 michael michael 1024 Jul 9 17:58 .
drwxrwxrwt 15 root root 5120 Jul 9 17:58 ..
-rw-r--r-- 1 michael michael 0 Jul 9 17:58 something
$ sleep 60
$ touch test
$ rm test
$ ls -al
total 6
drwxr-xr-x 2 michael michael 1024 Jul 9 17:59 .
drwxrwxrwt 15 root root 5120 Jul 9 17:58 ..
-rw-r--r-- 1 michael michael 0 Jul 9 17:58 something
I should hope that wouldn't mess up a working copy :)
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> I don't know if there's a danger, but someone (you? :-) has to think
> about whether it's consistent. Can files in the directory have mtimes
> newer than the directory itself?
Nope, because of the bubble-up effect in the repository. For example,
the last-commit-time of '/' is always equal to the date of the last
commit.
> Does a propchange on a directory affect its mtime? Etc. ad nauseam.
Hmmmm, yeah, I guess one could commit a propchange to a directory, and
then it would have a timestamp newer than its contents. I wonder if
that would mess up any working copies.
Maybe I'll just stay away from this problem for now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
> Well for one thing, you didn't even start on the interactions between
> changing directory timestamps and what happens in the WC during
> different SVN operations. There's a farily large number of cases that
> we
> have to consider. Remember, this is not just about "svn export", it's
> about "svn update" and "svn commit", too.
Actually the change discussed on this thread only applies to "svn export", and
that's all I've been talking about. Switching to commit timestamps in a working
copy is messy because Subversion needs to be able to perform comparisons on
them. Timestamps are also less useful in a working copy since you can use 'svn
log' and 'svn status' to get the same type of information they provide. So
nobody is proposing to change the timestamps in working copies. (At least not
now. It is, of course, possible and I wouldn't be surprised to see it happen in
the future).
> Did you notice that there's been no talk yet even about _why_ we
> should
> modify timestamps on directories? There can be more than one reason.
> You
> should start by making a list of the possible reasons for and against,
> and comparing the merits of each. _Then_ we can start making
> decisions.
[ I moved this quote up top since its on another fundamental issue]
If "svn export" doesn't set timestamps, the exported files and directories still
*have* timestamps, but they are set nondeterministically and don't convey much
meaning. So you wind up with something like:
foo.c 03:00:00
bar.h 03:00:01
baz.s 03:00:02
bum/ 03:00:03
bum/bitty.h 03:00:03
I don't really have a problem with this behavior, but I can understand if some
people prefer to have their "last modified" timestamps indicating actual
modification times instead of just conveying the fact that Joe Release Manager
began his export at 3 am and waited four seconds for it to finish.
Anyway, Ben recently committed a change that allows the last modified times of
individual files to be set to the commit times of the revisions in which they
were last "modified" (for some reasonable and easy-to-implement definition of
"modified"). So if the sources were last modified and checked in at 1 am, the
result is now:
foo.c 01:00:00
bar.h 01:00:00
baz.s 01:00:00
bum/ 03:00:03
bum/bitty.h 01:00:00
I *do* have a problem with this behavior because it treats directories
differently than files, and for no good reason. (You mentioned filesystem
semantics, Branko. Do you actually think that making file times represent commit
times, and directory times represent export times is a good choice of
semantics?)
Luckily though, Ben was discussing a way to do the same thing for directories as
he did for files (again, choosing some reasonable and easy-to-implement
definition of "last modified") until you jumped in with vague prophecies of
"danger" and apparently scared him off. I've been following up find out what in
the world you mean by danger and I think I know now. So, to answer your question
about reasons for and against, here's where we are now:
REASONS FOR MODIFYING DIRECTORY TIMESTAMPS ON EXPORT
-----------------------------------------------------------
1) It gives deterministic behavior. Timestamps will be the
same no matter when or where a particular revision
is exported instead of reflecting the time and
duration of the checkout.
2) Files and directories will no longer need to have their
last-modified times interpreted differently. They
will both refer to commit times instead of files
referring to commit times and directories to export
times.
REASONS AGAINST MODIFYING DIRECTORY TIMESTAMPS ON EXPORT
-----------------------------------------------------------
NONE
>>>> I think everybody can agree that a good behavior is one that sets
>>>> the last modified timestamp of each file and directory to the
>>>> commit
>>>> time of the revison in which that file or directory was last
>>>> "modified"
>>>>
>>>>
>>>>
>>> No, the only good behaviour is one that's correct, for some
>>> definition
>>> of correct. We don't even have an idea about that right now.
>>>
>>>
>>
>> Ok, so what makes a behavior that fits the above description
>> incorrect?
>>
> We didn't even decide what "modified" means, right?
Right. Thats why I said "a behavior" instead of "the behavior." A behavior that
fits the description is correct for any of the definitions of "modified" we've
discussed including the Windows 95 definition, the Unix/NT definition, the
"bubble up" definition, and any variants that do or don't count property changes
as "modifications".
I have no idea why any of these behaviors would be considered incorrect, so I
was hoping you'd pick a behavior and say what was wrong with it.
> ...
>>> We don't want to repeat the mistake we made with
>>> first the filesystem schema design, which had to be changed several
>>> times (once in a major way) to get us to the point where it's
>>> _almost_ correct.
>>>
>>>
>>
>> Choosing to set the timestamp on an exported directories does not in
>> any way constrain future design decisions. If you think it does, I'm
>> dying to hear how...
>>
>>
> Did I say it constrains future design decisions? I did not. I said
> want
> to see a good design that considers all aspects of the feature before
> anyone starts hacking away, so that we don't end up rewriting the
> thing 500 times.
We are obviously talking past each other here. You're on changes to working copy
code and I'm on exported directory timestamps. Still, the only reason you'd have
to do a major rewrite is if you wanted to change your design and the existing
code prevented your from doing so. You implied that setting directory timestamps
could neccessitate a major rewrite so I wondered what bearing directory
timestamps had on any larger design issue.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Branko Cibej wrote:
>
>
>>Russell Yanofsky wrote:
>>
>>
>>>... And the issues
>>>aren't that complex.
>>>
>>>
>>>
>>Aren't they? You haven't even spelled them out.
>>
>>
>
>I haven't? What did I miss?
>
Well for one thing, you didn't even start on the interactions between
changing directory timestamps and what happens in the WC during
different SVN operations. There's a farily large number of cases that we
have to consider. Remember, this is not just about "svn export", it's
about "svn update" and "svn commit", too.
>>>I think everybody can agree that a good behavior is one that sets
>>>the last modified timestamp of each file and directory to the commit
>>>time of the revison in which that file or directory was last
>>>"modified"
>>>
>>>
>>>
>>No, the only good behaviour is one that's correct, for some definition
>>of correct. We don't even have an idea about that right now.
>>
>>
>
>Ok, so what makes a behavior that fits the above description incorrect?
>
We didn't even decide what "modified" means, right?
>>>You could debate endlessly about whether to count.property changes,
>>>or changes to a file underneath a directory as "modifications." This
>>>is a bikeshed issue though, and I don't have any opinion on it.
>>>
>>>
>>>
>>It is definitely _not_ a bikeshed. It is a very basic question of the
>>semantics of the SVN filesystem. We've copied most of the behaviour
>>from
>>Unix filesystems, but not all by a long shot. We're talking about
>>basic filesystem design issues here; just because they're simple and
>>easy to understand for files doesn't mean you can just wave them away
>>for
>>directories.
>>
>>
>
>I'm not waving away the issue. I'm saying that there are multiple correct ways
>of choosing the directory timestamp, that different people may prefer different
>ways, and that it doesn't matter very much which way you choose in the end
>because directory timestamps are mostly ignored.
>
>Consider the different meanings of directory timestamps on windows 95 and
>windows NT. On windows 95, a directory is stamped once at the time of creation
>and is never updated, even if files are added and removed from the directory. On
>windows NT, the directories are timestamped when created, but get new stamps
>whenever files are added and deleted from them.
>
>You can't argue that one behavior or the other is incorrect. Depending on what
>information you'd like to know either type of timestamp could be useful to you.
>
>
>Since subversion keeps a complete filesystem history, it could stamp exported
>directories with Windows 95-type timestamps, Windows NT timestamps, a unix
>timestamps or a completely new type of timestamp.
>
Sigh. You keep on talking about behaviour on various filesystems. What
we have is a _versioned_ filesystem plus a working copy; with whole
dimensions of behaviour that aren't even applicable to ordinary file
systems.
>>>I think the best thing to do now is to choose whatever meaning of
>>>"modification" gives the simplest implementation.
>>>
>>>
>>>
>>Almost -- not just the simplest, but one that's consistent in all
>>circumstances.
>>
>>
>
>Agreed. But AFAICT, *you* are the one proposing inconsitent behavior. The status
>quo is inconsistent in two respects:
>
No, I am not proposing it. What I'm proposing is to leave well enough
alone until we _do_ figure out what's consistent.
>1) Files get commit timestamps while directories get stamped with the time of
>export.
>2) Timestamps depend on the time of export, so the an export at 5 o'clock looks
>different from an export of the same revision at 6 o'clock.
>
>
>
>>>Due to bubbling up, this should mean that a
>>>directory will get assigned the timestamp of the most recent
>>>revision with changes to files or properties underneath it.
>>>
>>>
>>>
>>I say again: bubble-up is an implementation detail. Changes that
>>result _only_ from bubble-up should not affect the filesystem's
>>behaviour. When
>>you commit /foo/bar, you don't commit a change to / at the same time.
>>
>>
>
>The behavior I described would be facilitated by bubble up, but not dependent on
>it. An implementation that did not use bubble up could give the exact same
>results.
>
You described a behaviour that you think would be good, but you haven't
demonstrated that it's resonably or self-consistent. So yes, you're
talking about a bikeshed, but _I'm_ talking about sitting down and
figuring out a good design. Two different things, wouldn't you say?
>Personally, I think it would be great if the modification time of / reflected
>changes to /foo/bar. That way you would be able to tell at a glance if something
>changed recently underneath a directory, without having to look inside. But for
>some reason you fancy a different behavior. That's perfectly ok too. This is a
>bikeshed.
>
>
>
>>>But just about anything is better than the current behavior of
>>>stamping files with commit times and directories with the time of
>>>export.
>>>
>>>
>>>
>>>
>>I disagree. We should leave well enough alone until we figure out how
>>to
>>do things correctly.
>>
>>
>
>The current behavior is inconsistent, while the behavior Ben described is
>correct and easy to implement.
>
How d'you know it's correct without exploring all the edge cases and
interactions with svn operatoins?
>>We don't want to repeat the mistake we made with
>>first the filesystem schema design, which had to be changed several
>>times (once in a major way) to get us to the point where it's _almost_
>>correct.
>>
>>
>
>Choosing to set the timestamp on an exported directories does not in any way
>constrain future design decisions. If you think it does, I'm dying to hear
>how...
>
>
Did I say it constrains future design decisions? I did not. I said want
to see a good design that considers all aspects of the feature before
anyone starts hacking away, so that we don't end up rewriting the thing
500 times.
Did you notice that there's been no talk yet even about _why_ we should
modify timestamps on directories? There can be more than one reason. You
should start by making a list of the possible reasons for and against,
and comparing the merits of each. _Then_ we can start making decisions.
Maybe you think that's too much work for such a "trivial" feature. Well,
Subversion didn't get where it is now by pooh-poohing away issues like
this as trivial. Witness how much discussion was spent on _file_ mtimes
before we finally got that feature in. Directory mtimes are an order of
magnitude more complex.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
> Russell Yanofsky wrote:
>> ... And the issues
>> aren't that complex.
>>
> Aren't they? You haven't even spelled them out.
I haven't? What did I miss?
>> I think everybody can agree that a good behavior is one that sets
>> the last modified timestamp of each file and directory to the commit
>> time of the revison in which that file or directory was last
>> "modified"
>>
> No, the only good behaviour is one that's correct, for some definition
> of correct. We don't even have an idea about that right now.
Ok, so what makes a behavior that fits the above description incorrect?
>> You could debate endlessly about whether to count.property changes,
>> or changes to a file underneath a directory as "modifications." This
>> is a bikeshed issue though, and I don't have any opinion on it.
>>
> It is definitely _not_ a bikeshed. It is a very basic question of the
> semantics of the SVN filesystem. We've copied most of the behaviour
> from
> Unix filesystems, but not all by a long shot. We're talking about
> basic filesystem design issues here; just because they're simple and
> easy to understand for files doesn't mean you can just wave them away
> for
> directories.
I'm not waving away the issue. I'm saying that there are multiple correct ways
of choosing the directory timestamp, that different people may prefer different
ways, and that it doesn't matter very much which way you choose in the end
because directory timestamps are mostly ignored.
Consider the different meanings of directory timestamps on windows 95 and
windows NT. On windows 95, a directory is stamped once at the time of creation
and is never updated, even if files are added and removed from the directory. On
windows NT, the directories are timestamped when created, but get new stamps
whenever files are added and deleted from them.
You can't argue that one behavior or the other is incorrect. Depending on what
information you'd like to know either type of timestamp could be useful to you.
Since subversion keeps a complete filesystem history, it could stamp exported
directories with Windows 95-type timestamps, Windows NT timestamps, a unix
timestamps or a completely new type of timestamp.
>> I think the best thing to do now is to choose whatever meaning of
>> "modification" gives the simplest implementation.
>>
> Almost -- not just the simplest, but one that's consistent in all
> circumstances.
Agreed. But AFAICT, *you* are the one proposing inconsitent behavior. The status
quo is inconsistent in two respects:
1) Files get commit timestamps while directories get stamped with the time of
export.
2) Timestamps depend on the time of export, so the an export at 5 o'clock looks
different from an export of the same revision at 6 o'clock.
>> Due to bubbling up, this should mean that a
>> directory will get assigned the timestamp of the most recent
>> revision with changes to files or properties underneath it.
>>
> I say again: bubble-up is an implementation detail. Changes that
> result _only_ from bubble-up should not affect the filesystem's
> behaviour. When
> you commit /foo/bar, you don't commit a change to / at the same time.
The behavior I described would be facilitated by bubble up, but not dependent on
it. An implementation that did not use bubble up could give the exact same
results.
Personally, I think it would be great if the modification time of / reflected
changes to /foo/bar. That way you would be able to tell at a glance if something
changed recently underneath a directory, without having to look inside. But for
some reason you fancy a different behavior. That's perfectly ok too. This is a
bikeshed.
>> But just about anything is better than the current behavior of
>> stamping files with commit times and directories with the time of
>> export.
>>
>>
> I disagree. We should leave well enough alone until we figure out how
> to
> do things correctly.
The current behavior is inconsistent, while the behavior Ben described is
correct and easy to implement.
> We don't want to repeat the mistake we made with
> first the filesystem schema design, which had to be changed several
> times (once in a major way) to get us to the point where it's _almost_
> correct.
Choosing to set the timestamp on an exported directories does not in any way
constrain future design decisions. If you think it does, I'm dying to hear
how...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Branko Cibej wrote:
>
>
>>>I think it would be a mistake to treat file times differently than
>>>directory times without some specific reason for doing so.
>>>
>>>
>>>
>>It would be a vastly bigger mistake to start fiddling with directory
>>mtimes without understanding the issues.
>>
>>
>
>You're overstating. Ben could choose to stamp all directories with his birthday
>and it probably wouldn't break a thing. And the issues aren't that complex.
>
Aren't they? You haven't even spelled them out.
>I think everybody can agree that a good behavior is one that sets the last
>modified timestamp of each file and directory to the commit time of the revison
>in which that file or directory was last "modified"
>
No, the only good behaviour is one that's correct, for some definition
of correct. We don't even have an idea about that right now.
>You could debate endlessly about whether to count.property changes, or changes
>to a file underneath a directory as "modifications." This is a bikeshed issue
>though, and I don't have any opinion on it.
>
It is definitely _not_ a bikeshed. It is a very basic question of the
semantics of the SVN filesystem. We've copied most of the behaviour from
Unix filesystems, but not all by a long shot. We're talking about basic
filesystem design issues here; just because they're simple and easy to
understand for files doesn't mean you can just wave them away for
directories.
>I think the best thing to do now is to choose whatever meaning of "modification"
>gives the simplest implementation.
>
Almost -- not just the simplest, but one that's consistent in all
circumstances.
>Due to bubbling up, this should mean that a
>directory will get assigned the timestamp of the most recent revision with
>changes to files or properties underneath it.
>
I say again: bubble-up is an implementation detail. Changes that result
_only_ from bubble-up should not affect the filesystem's behaviour. When
you commit /foo/bar, you don't commit a change to / at the same time.
>But just about anything is better than the current behavior of stamping files
>with commit times and directories with the time of export.
>
>
I disagree. We should leave well enough alone until we figure out how to
do things correctly. We don't want to repeat the mistake we made with
first the filesystem schema design, which had to be changed several
times (once in a major way) to get us to the point where it's _almost_
correct.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
> ...
> It's not about whether dir mtimes can/should be set, but _how_ to do
> it correctly in a version-controlled environment.
Ok. I (and apparently Michael Wood and Jack Repenning) thought you were also
making an argument again directory mtimes on grounds of OS limitations.
>> I think it would be a mistake to treat file times differently than
>> directory times without some specific reason for doing so.
>>
> It would be a vastly bigger mistake to start fiddling with directory
> mtimes without understanding the issues.
You're overstating. Ben could choose to stamp all directories with his birthday
and it probably wouldn't break a thing. And the issues aren't that complex.
I think everybody can agree that a good behavior is one that sets the last
modified timestamp of each file and directory to the commit time of the revison
in which that file or directory was last "modified"
You could debate endlessly about whether to count.property changes, or changes
to a file underneath a directory as "modifications." This is a bikeshed issue
though, and I don't have any opinion on it.
I think the best thing to do now is to choose whatever meaning of "modification"
gives the simplest implementation. Due to bubbling up, this should mean that a
directory will get assigned the timestamp of the most recent revision with
changes to files or properties underneath it.
But just about anything is better than the current behavior of stamping files
with commit times and directories with the time of export.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Branko Cibej wrote:
>
>
>>Oh, by the way: lying about the modification time of a directory is
>>generally not a good idea, and it's not something "make" is
>>interested in. Let's think carefully about what we want to achieve
>>here before starting to change directory mtimes.
>>...
>>It's simple with files, not so simple with directories -- as we've
>>found
>>to our detriment (remember all the ghurson problems).
>>
>>
>
>I tried searching back for ghudson/directory timestamp posts, but couldn't find
>anything. Do you remember (generally) what the problems were about?
>
The infamous "ghudson problems" are about versioning directories, not
specifically about timestamps. They demonstrate that version controlled
directories are way more complex beasts than you'd imagine.
>I can't imagine why there would be any problem.
>
Yes, I see. Doesn't mean there isn't one. :-)
>Why would an OS implement a
>function to set an arbitrary directory time if it couldn't actually handle
>arbitrary directory times? And if ubiquitous tools like 'tar' and 'touch' can
>set directory times freely, why can't 'svn export'?
>
It's not about whether dir mtimes can/should be set, but _how_ to do it
correctly in a version-controlled environment.
>I think it would be a mistake to treat file times differently than directory
>times without some specific reason for doing so.
>
>
It would be a vastly bigger mistake to start fiddling with directory
mtimes without understanding the issues.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
> Oh, by the way: lying about the modification time of a directory is
> generally not a good idea, and it's not something "make" is
> interested in. Let's think carefully about what we want to achieve
> here before starting to change directory mtimes.
> ...
> It's simple with files, not so simple with directories -- as we've
> found
> to our detriment (remember all the ghurson problems).
I tried searching back for ghudson/directory timestamp posts, but couldn't find
anything. Do you remember (generally) what the problems were about?
I can't imagine why there would be any problem. Why would an OS implement a
function to set an arbitrary directory time if it couldn't actually handle
arbitrary directory times? And if ubiquitous tools like 'tar' and 'touch' can
set directory times freely, why can't 'svn export'?
I think it would be a mistake to treat file times differently than directory
times without some specific reason for doing so.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>Oh, by the way: lying about the modification time of a directory is
>>generally not a good idea, and it's not something "make" is interested
>>in. Let's think carefully about what we want to achieve here before
>>starting to change directory mtimes.
>>
>>
>
>Bad idea to set mtimes?
>
>At the moment, I have 'svn export' setting mtimes on files. I figured
>that the export editor's close_directory() could do the same. I mean,
>directories are versioned objects in svn. What's the danger in
>setting their mtime to last-commit-time?
>
I don't know if there's a danger, but someone (you? :-) has to think
about whether it's consistent. Can files in the directory have mtimes
newer than the directory itself? If so, is that reasonable, on all
systems? Does a propchange on a directory affect its mtime? Etc. ad nauseam.
It's simple with files, not so simple with directories -- as we've found
to our detriment (remember all the ghurson problems).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs commit: apr/test testfileinfo.c
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Oh, by the way: lying about the modification time of a directory is
> generally not a good idea, and it's not something "make" is interested
> in. Let's think carefully about what we want to achieve here before
> starting to change directory mtimes.
Bad idea to set mtimes?
At the moment, I have 'svn export' setting mtimes on files. I figured
that the export editor's close_directory() could do the same. I mean,
directories are versioned objects in svn. What's the danger in
setting their mtime to last-commit-time?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org