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

[Geoff Rowell <ge...@gmail.com>]

On Fri, Feb 5, 2010 at 9:42 PM, Ed <ed...@kdtc.net> wrote:
> Philipp Marek wrote:
>>
>> 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.
>
> No. No need for apologies.  Just my tendency to be
> confused easily. :)
>
>>
>>> 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)
>
> I hope there's some sort of consensus this time around.
>
>>
>>> 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!
>
> Is my spec similar to yours?  With Bert's comments in mind, the
> current spec should be changed to reflect that if the mtime property
> doesn't exist then svn shouldn't even bother with adding it.  It
> only adds mtime properties to newly imported/added files.
>
>
>>
>>
>>>>>
>>>>> +    - 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).
>
> It brings me to thinking would the operating system permit svn to update
> the mtime M(x) = R'(x) if the user is still editing the file?  Would
> there be an access denied error?
>
>>> 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.
>
> Good.  Thanks for the clarification.
>
>>> 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).
>
> Does svntar, fsvs and svn+branch use the text-time property as if it is
> the mtime property?  I'm not familiar with svntar, fsvs and svn+branch.
>
>>
>>>>>
>>>>> +  ... 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.
>
> Oh.  Good point.  Didn't think about the 'make' issue.
>
>> 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.
>
> Now I understand.  Thanks.
>
>>
>> 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.
>>
>
> I still feel that if this specification goes through RFC and is ok'd,
> then wouldn't it be easier to take your implementation and modify it
> to whatever the revised specification states; wouldn't this be a lot
> easier?  While the specification itself is bite sized, I don't think
> the actual implementation is. (or is it?)  Was your solution bite-sized?
>
> Btw, regarding the RFC I submitted.  Was I supposed to send it as
> a diff, or a text file?   (I realize it is a moot point right now,
> but for future reference, I think it would be nice to get this
> clarified. :)).
>
Due to the potentially ubiquitous nature of this property, some
consideration needs to be given to when and where the mtime property
modification is reported for the affected files and folders.

Sometime? Always? Never?
--
Geoff Rowell
geoff.rowell@gmail.com

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

["Ph. Marek" <ph...@emerion.com>]

Hello Julian!

>> > Due to the potentially ubiquitous nature of this property, some
>> > consideration needs to be given to when and where the mtime property
>> > modification is reported for the affected files and folders.
>> >
>> > Sometime? Always? Never?
>>
>> With the current ra layer the answer would probably be: Always.
>
> I don't think the question wanted a simple answer. The point is that the
> design of this feature must consider whether it would often cause
> "noise" by causing mtime changes to be reported when they are not
> interesting.
>
> There are two sides to this. First on the repository side: if the design
> would often cause mtime property changes to be committed on files that
> have not otherwise changed, then, because of the fact that the current
> RA layer reporting mechanisms would just report "this file has changed",
> that would be bad. That needs to be considered especially after updates
> and reverts, I should think.
In my branch that would be a non-issue.
As the property would be changed on a commit, only files that get  
committed (ie. that are really changed, or at least have other  
property changes) would have a changed svn:text-time.

> The other half of the issue is when svn is reporting local WC changes in
> a simple "svn status" or "svn diff" command: how does the design ensure
> that only useful changes are reported here?
The same happens locally - the changed svn:text-time is simply not  
seen, because it's just a property that gets sent along to the server.

Of course, that means that a mtime-only change (think "touch") cannot  
easily be committed.


Regards,

Phil

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

["Ph. Marek" <ph...@emerion.com>]

Hello Julian!

>> > Due to the potentially ubiquitous nature of this property, some
>> > consideration needs to be given to when and where the mtime property
>> > modification is reported for the affected files and folders.
>> >
>> > Sometime? Always? Never?
>>
>> With the current ra layer the answer would probably be: Always.
>
> I don't think the question wanted a simple answer. The point is that the
> design of this feature must consider whether it would often cause
> "noise" by causing mtime changes to be reported when they are not
> interesting.
>
> There are two sides to this. First on the repository side: if the design
> would often cause mtime property changes to be committed on files that
> have not otherwise changed, then, because of the fact that the current
> RA layer reporting mechanisms would just report "this file has changed",
> that would be bad. That needs to be considered especially after updates
> and reverts, I should think.
In my branch that would be a non-issue.
As the property would be changed on a commit, only files that get  
committed (ie. that are really changed, or at least have other  
property changes) would have a changed svn:text-time.

> The other half of the issue is when svn is reporting local WC changes in
> a simple "svn status" or "svn diff" command: how does the design ensure
> that only useful changes are reported here?
The same happens locally - the changed svn:text-time is simply not  
seen, because it's just a property that gets sent along to the server.

Of course, that means that a mtime-only change (think "touch") cannot  
easily be committed.


Regards,

Phil

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

[Julian Foad <ju...@wandisco.com>]

> > Ed wrote:
> > > Btw, regarding the RFC I submitted.  Was I supposed to send it as
> > > a diff, or a text file?   (I realize it is a moot point right now,
> > > but for future reference, I think it would be nice to get this
> > > clarified. :)).

As we don't have a base version in the repository yet, for any updates I
would prefer you to send both the diff and the new full text.

Bert Huijben wrote: 
> Geoff Rowell wrote:
> > Due to the potentially ubiquitous nature of this property, some
> > consideration needs to be given to when and where the mtime property
> > modification is reported for the affected files and folders.
> > 
> > Sometime? Always? Never?
> 
> With the current ra layer the answer would probably be: Always.

I don't think the question wanted a simple answer. The point is that the
design of this feature must consider whether it would often cause
"noise" by causing mtime changes to be reported when they are not
interesting.

There are two sides to this. First on the repository side: if the design
would often cause mtime property changes to be committed on files that
have not otherwise changed, then, because of the fact that the current
RA layer reporting mechanisms would just report "this file has changed",
that would be bad. That needs to be considered especially after updates
and reverts, I should think.

The other half of the issue is when svn is reporting local WC changes in
a simple "svn status" or "svn diff" command: how does the design ensure
that only useful changes are reported here?

- Julian


[...]

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

[Julian Foad <ju...@wandisco.com>]

> > Ed wrote:
> > > Btw, regarding the RFC I submitted.  Was I supposed to send it as
> > > a diff, or a text file?   (I realize it is a moot point right now,
> > > but for future reference, I think it would be nice to get this
> > > clarified. :)).

As we don't have a base version in the repository yet, for any updates I
would prefer you to send both the diff and the new full text.

Bert Huijben wrote: 
> Geoff Rowell wrote:
> > Due to the potentially ubiquitous nature of this property, some
> > consideration needs to be given to when and where the mtime property
> > modification is reported for the affected files and folders.
> > 
> > Sometime? Always? Never?
> 
> With the current ra layer the answer would probably be: Always.

I don't think the question wanted a simple answer. The point is that the
design of this feature must consider whether it would often cause
"noise" by causing mtime changes to be reported when they are not
interesting.

There are two sides to this. First on the repository side: if the design
would often cause mtime property changes to be committed on files that
have not otherwise changed, then, because of the fact that the current
RA layer reporting mechanisms would just report "this file has changed",
that would be bad. That needs to be considered especially after updates
and reverts, I should think.

The other half of the issue is when svn is reporting local WC changes in
a simple "svn status" or "svn diff" command: how does the design ensure
that only useful changes are reported here?

- Julian


[...]

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

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Geoff Rowell [mailto:geoff.rowell@gmail.com]
> Sent: zaterdag 6 februari 2010 14:26
> To: Ed
> Cc: Philipp Marek; dev@subversion.apache.org
> Subject: Re: [RFC] MTime functional specifications (v2.0)


> >
> > I still feel that if this specification goes through RFC and is ok'd,
> > then wouldn't it be easier to take your implementation and modify it
> > to whatever the revised specification states; wouldn't this be a lot
> > easier?  While the specification itself is bite sized, I don't think
> > the actual implementation is. (or is it?)  Was your solution bite-
> sized?
> >
> > Btw, regarding the RFC I submitted.  Was I supposed to send it as
> > a diff, or a text file?   (I realize it is a moot point right now,
> > but for future reference, I think it would be nice to get this
> > clarified. :)).
> >
> Due to the potentially ubiquitous nature of this property, some
> consideration needs to be given to when and where the mtime property
> modification is reported for the affected files and folders.
> 
> Sometime? Always? Never?

With the current ra layer the answer would probably be: Always.

In functions like 'svn status' and 'svn log' we just get the boolean
indicating that one or more properties are changed. Providing more
information would require extensive RA layer changes.

We have some existing issues that indicate that this is a known problem for
'svn:mergeinfo' and you will most likely see only more changes for the
timestamp property. svn log would only indicate that the file was changed..
not if it is a textual change, a property change or a timestamp change.
(If repository and client are 1.7+ you could see if the change is on a
property or textual; but we are not there yet)


I would suggest that if/when we are going to implement a change from this
change-reporting, that we should also look to svn:mergeinfo.


	Bert