(snip)
> >> Merge is likely to cause conflicts in the new properties, is that
> >> acceptable? Should Subversion automatically "resolve"
> >> such conflicts?
> >
> > Conflict is naturally resolved by having the latest win.
>
> I suspect the conflicts should be resolved, I'm not sure that
> the latest is the natural choice.
Could you elaborate on that, give an example where the latest is not the
natural choice? (For the time-stamps obviously - not the contents).
>
> >> If the user changes a file's timestamp but doesn't change
> the text or
> >> any properties, should Subversion detect that?
> >
> > Yes. In fact that's what it does today, no? It uses the
> file-times on
> > the client to detect any change, it does not run any diffs
> or hashes
> > on the sources to detect changes.
>
> No, as I understand it, the current code does not detect such
> timestamp changes, they do not show up in the status output,
> and the only way to commit a timestamp change is to
> explicitly propset.
Just how does Subversion detect a modified file then? I don't believe that
it scans through all files, comparing bit-by-bit or hashing. I supoose it
stores the last-modified-time in the client-side mirror, and does a diff
when the time-stamps differ. Correction, anyone?
>
> >> On Unix only the owner of a file can change it's timestamp to
> >> anything other than the current time. To allow multiple users to
> >> share working copies it might be necessary to do the
> >> "move-copy-delete" dance to get ownership. (I wonder if
> this affects
> >> the existing use-commit-times
> >> code?)
> >
> > As you say, this issue must already exist/be solved with
> use-commit-times.
>
> "Must" is optimistic on your part :)
Ah, well, the "must" applies equally to "this issue already exists" as to
"be solved"...
>
> > Anyone know how that is handled there?
>
> If you compare the code that sets the permissions with the
> code that sets the timestamp then the permissions code does
> "move-copy-delete"
> to gain ownership and the timestamp code does not. I suspect
> that at present we usually set timestamps when creating files
> and so nothing goes wrong, but if we start setting timestamps
> more often then we might need to do something more. It's not
> hard to do, we know how to solve the problem, I'm just
> pointing out that there are corner cases to consider.
Good point.
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 20:11:18 2005