(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.
> 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.
> BTW - This is even more complex that it looks since if you
> edit what is in,
> say, the $Id: xxxxx $ string, and thus the file is actually
> different but
> not really (since that string is managed by SVN) then "svn
> status" will still
> show the file as unchanged.
That's yet another possible scenario. I'd still prefer that the the
timestamp that's in my working copy after that operation get's propagated to
another working copy if I perform a commit. If I decide to do a revert I
want the timestamp to go back to what it was.
>
> > 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.
> 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.
> >>Does it show up as text modifed 'M ', property modifed ' M',
> >>or some other timestamp modified indicator?
> >
> > I'd say "text modified 'M'"".
>
> Show me where the text is modified. In source code or ASCII
> text of Word
> documents, if someone tells me that there is a difference, I
> would expect
> that "diff" (or some equiv tool) would show me what changed.
> If there is
> nothing to show, it would seem to me that telling me that
> there is a text
> change is wrong/a bug.
Well... This can certainly be discussed, but I'd expect that SVN would
indeed tell me that it was the timestamp that had changed. Even if we for
convenience sake used a common indicator in the CLI/GUI.
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 23:29:58 2005