Svante Seleborg wrote:
> (snip)
>
>>>>So status will show some sort of "modified" indicator whenever the
>>>>filesystem timestamp and the property timestamp don't match?
>>>
>>>
>>>Not some sort of "modified" - just plain modified. Just as
>>
>>if you had indeed
>>
>>>modified the contents too. Generally speaking that is the
>>
>>current behavior.
>>
>>I do not understand why you keep bringing this up. Currently
>>(1.2.1 and earlier)
>>SVN did actually check the file contents for modification.
>>Try it, you may
>>be surprised.
>
>
> That is not what is at issue here. We're discussion the future design of how
> to handle filesystem timestamp metadata.
Ahh, but you have brought up that is what SVN does today, which
is not true. The timestamp is not the only indicator/exclusive
indicator of file changes.
If you are proposing a change to this then I would think that there
are many, many other issues that will come up, not the least of
which will be the broken build process (for anyone using timestamps
such as Make uses)
>>In fact, it is a nice thing to have a file that was edited a
>>few times and
>>then turns out to be the same as it was since the last commit
>>end up showing
>>in "svn status" as not modified even with the time stamps updated.
>
> That is one possible scenario. Unfortunately "nice thing" is in my mind a
> lesser priority than "breaks build", or "looses relevant history". The
> proposed design still allows for the current behavior, according to taste.
Well, usually, the thing that breaks a build is a repository update
(svn up) where the timestamp of the file is not "now" after it has
been changed. The reason this breaks the build is this:
1) Person A and B start out with revision (n)
2) Person A makes some changes
3) Person B does a build still at revision (n)
4) Person A does a commit to revision (n+1)
4) Person B does an "svn up"
5) Person B does another build.
Now, if file foo.c retained the timestamp of the file modification time
from person A, the build for person B would fail (well, if done based on
modification times, which is what I seem to hear you saying) since the
resulting object file (foo.o) would be newer than the source (foo.c)
even though the source was actually updated by the svn update operation.
Now, that is not to say that there are no cases where I would like the
file timestamps tracked. Just like I would like other meta-data tracked.
But if you are looking to help the build process, this is the wrong way
to do it.
BTW - I *do* want the import operation to track the timestamps of the
files as this is the first commit. In fact, I may also want that
for the general commits, just as other meta-data.
>>>If you modify the filesystem timestamp, it'll show up as
>>
>>modified until you
>>
>>>try to commit, at which time it'll decide there was no
>>
>>"real" change. The
>>
>>>proposed design would consider a timestamp change a "real"
>>
>>change all on
>>
>>>its own.
>>
>>Well, depends on what you are calling a "real change" - Any
>>meta-data change
>>is a "real change" but it is not a change to the file
>>contents. That is currently
>>the way Subversion works and is, in some ways, proper. There
>>is a difference
>>between meta-data and data, albeit an arbitrary difference,
>>there is a difference.
>>Mostly this is due to the way we (as people) tend to view the
>>data of the
>>file vs the meta-data of the file.
>
>
> If we were versioning data streams, I'd be more likely to view it that way.
> But we're not. We're versioning files. They have, as a very tightly coupled
> item, one or several pieces of meta-data attached. In current file systems
> this is pretty much limited to timestamps, but no less important.
>
> I will maintain that import/commit followed by export/checkout should
> preserve the identity relation between the two sets as far as possible,
> including file names and file timestamps. Timestamps are an important piece
> of the history of a project. This currently gets irrevocable lost once
> imported into SVN.
I maintain that it is not so simple. The "modified" timestamp can have two
different meanings, both of which are valid.
1) Actual time the file was modified *anywhere*
2) The time the file was modified *here* (known to this system)
The problem is that many, many tools assume that these two values are
the same thing when, in fact, they are not. One is the timestamp of
the change to the data "in the global view" while the other is the
timestamp of when I first saw the change. From my computer's perspective,
the file changed at the time I did the "svn up" and not when someone
else last did the save (or when they did the commit - which are not
the same)
In fact, lets look at this from a backup standpoint - if you do backups based
on all files that were changed (timestamp) after your last backup, would
you not expect that any file that is different since the last backup would
be included, even if that file came from SVN? But if you set the timestamp
(last changed) of the file to that of when the person doing the commit last
did the save before the commit, this could be days, weeks, even months earlier
than when you got the update.
Now, if systems had a concept of last modified (contents) and last modified
(on this system) dates, then things would be clearer. Unfortunately, not
since VMS have I seen a generally used filesystem that had such features.
(But then VMS also had versioning in the filesystem too :-)
>>A picture will look exactly the same no matter what the
>>timestamp says or the
>>execute bit setting is.
>
> Yes, but *you* might be interested when that picture was taken - not only
> when it was placed into the new and shiny album you bought a few years
> later. I'd be mighty annoyed if the time the picture was taken was available
> before putting it into the album, and then changed to reflect the time when
> I put it into the albubm, and even worse not being able to get that time
> back when I decide to take it out of the album again.
I agree that I would be interested in when the picture was taken. Also with
what camera, and lens type, exposure, etc. If this is not part of the picture
(pretend EXIF does not exist) then that is meta-data for the picture. And
just like any other meta-data, it should be versioned, tracked, and accessable.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 20 00:34:06 2005