> -----Original Message-----
> From: Philipp Marek [mailto:philipp.marek_at_emerion.com]
> Sent: vrijdag 5 februari 2010 9:48
> To: dev_at_subversion.apache.org
> Cc: Ed
> Subject: Re: [RFC] MTime functional specifications (v2.0)
>
> 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.
I would suggest making it default *not* to store these timestamps.
If we are going to store them by default, a new client will introduce this
property everywhere (even on existing repositories). Users of older clients
can then no longer merge new revisions because this property will always
conflict with versions on another branch. (We can't learn 1.0-1.6 clients
that they should always just replace the old property value, when we release
1.7/1.8)
We really need better property conflict resolving before I would enable such
a change.
When we would introduce this issue 'as-is' on trunk, we would start
introducing this property on the ASF repository now, as at least a few
Subversion developers use trunk for their development work.
I think that would even require changes to the post-commit mailer script
before we actually release 1.7.
(I don't think we would have used a normal svn: property for storing
mergeinfo if we knew back then what we know today.)
> 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.
This would be a solution to the problem mentioned above: Only change it if
the file needs the timestamp stored, just like svn:needs-lock.
(In that case the user decided that it wants to break certain older client
features)
Bert
Received on 2010-02-05 13:08:47 CET