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. :)).
Edmund
Received on 2010-02-06 03:43:10 CET