[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] MTime functional specifications (v2.0)

From: Philipp Marek <philipp.marek_at_emerion.com>
Date: Fri, 5 Feb 2010 09:47:49 +0100

Hello Ed!

On Freitag, 5. Februar 2010, Ed wrote:
> As usual, thanks for the prompt comments.
I think I have to apologize - I seem to cause confusion.

> All of those patches I was referring to were your patches as included in
> the issue 1256 attachment list. Just a cursory query. If there exists
> a full implementation of 'mtime', (I really should look at the contents
> of the branches more often) this means it's already been implemented.
*Something* is already implemented.
But that's not accepted into mainline, because there was just my
implementation, and no consensus about the specification.
(Mostly because nobody had time at that time, that was around 0.35, so before
the 1.0 release)

> Is the point of a functional spec to flush out the details of the
> implementation? Or should I just follow the implementation and
> apply the functional specs according to what is implemented. (Or does
> this make any sense? )
No, a specification should be done first.
I had one, for the behaviour I needed - which I implemented then.
So my "description" of the branch is the "specification" of it, too.

But it's entirely possible that other behaviour is wanted - that's why you re-
open the discussion, after all!

 
> >> + - Whenever Subversion modifies a file (or directory) in the WC, and
> >> + there are local changes to that node, such as when updating a
> >> file + that the user has been editing, it shall update the mtime
> >> property.
> >
> > This isn't implemented in the branch, AFAIR.
>
> I wasn't really sure about this point. I'm assuming that the user
> had saved some changes (motto: save often :)), so then the actual
> on-disk mtime would change. Then if the user updates his/her WC,
> here's where I'm iffy.
Sorry, I meant *exactly* that it's (AFAIR) not implemented. It makes a lot of
sense, but I fear that the branch will just "apply" the newly fetched R'(x).

> If user A edits x with mtime M(x) and repository mtime of R(x), then
> user B commits a change to x and commits it then R(x) becomes R'(x).
> Then if user A edits his/her WC's x, thus M(x) becomes M'(x) and
> then updates his/her WC. Then the system will compare R'(x) and
> M'(x). Maybe I'm getting confused, but isn't that in itself
> a conflict of properties?
In my branch the property was overwritten on the actual commit.
So if the user didn't manually change the property, the stored value will
locally still be M(x), so the update doesn't see any conflict.

M'(x) would be generated on the commit.

> >> + Mtime shall be stored in a versioned property named 'svn:mtime'.
> >> + Any file or directory may have this property. The format of the
> >> + property value is 'YYYY-MM-DDTHH:MM:SS.UUUUUU' of which the time
> >> + is UTC.
> >
> > Very fine. And if you change that to "svn:text-time", this is already
> > specified in svn_props.h:
> >
> > https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_
> >props.h
>
> If it's already defined in svn_props.h, then it's a lot easier to
> use the existing one (would users expect it to be called 'mtime',
> since using 'text-time' might mean that it can only be used for
> text files as opposed to binary files?).
No, "text" means "data" here, as opposed to "ctime" for "inode time".
In the WC library there was the data often named "text", that's where it comes
from.

(I'd hope that this name doesn't hurt ... and nowadays it's used in at least 3
programs [svntar, fsvs, and svn+branch], so it probably shouldn't be changed
now).
 
> >> + ... This functional specification takes
> >> + the tact of setting the 'svn:mtime' property to the current
> >> + mtime as it will give the user at least a starting point
> >> + to which to make their statistical/informational mtime references.
> >
> > So there's no way to have some part of the WC with mtime-storage, and
> > another without? I'm thinking about generated binaries that you want to
> > keep.
>
> Pardon me for being a bit dense. Do you mean that generated binaries
> (or binaries in general?) should not have the 'mtime' stored?
No ...
If you've got some source files, you *don't* want mtime stored for them, so
that "make" knows what to re-compile.
But if you want to keep the generated binaries (and especially if there's some
3rd party dependence, eg. on some DLLs), you *want* the mtime - because that's
the easiest thing to compare over a phone line.

So it's entirely possible that some files shall have the mtime stored, while
others shouldn't.

In my branch that was "solved" by the auto-props - I extended them to apply to
directories, too (someway, don't remember now), so that for certain file- (and
directory) specifications "svn:text-time" could be set to "yes" on "svn add";
this would automatically be changed to the correct value on commit.

Regards,

Phil
Received on 2010-02-05 09:48:20 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.