On 10/9/06, Ph. Marek <philipp.marek@bmlv.gv.at> wrote:
> Hello Erik,
> hello everybody else,
>
> I'd like to give two comments to this summary.
>
>
> On Monday 09 October 2006 00:03, Erik Huelsmann wrote:
> > Both Julian Foad and Philip Marek point out that copy and move aren't
> > so similar, so, I decided to split this one up in Copy and Move.
> >
> > Copy
> > Copy does not maintain the old value of the MTIME_RECORD: as soon as
> > the copy is committed (or it is a wc->repos copy), a new value (the
> > time of the copy) is stored in the MTIME_RECORD.
>
> To this I said:
> | And because it's stored as a property, it would have to be hard-coded to get
> | deleted on copy.
All of the current behaviours would have to be hard-coded. Even if the
copy operation itself keeps the mtime property, committing the file
would result in the commit taking the current time to be the mtime to
assign, since that's how it currently proposed to be implemented: so,
there'd be a hardcoded rule to exclude copies for that behaviour - not
on copy, but at commit time.
> Please, keep it. I remember no usage of "cp" or "rsync"
> | without "-a"!
> If you do "svn cp foo bar", the data *and* properties get copied, right? So
> I'd expect that the mtime property would get copied too.
yup. as explained above.
> But maybe I should clarify:
> WC -> WC: Does not maintain mtime currently; would need a parameter "-a" to
> keep. Else we'd commit a different mtime for the copied item (which might or
> might not be what was intended)
> REPOS -> REPOS: Would more or less do a "hardlink" in the repository, ie.
> keep the mtime.
exactly
> WC -> REPOS: should take the current mtime of the item?
a WC->REPOS copy is effectively a commit... So, yes.
> REPOS -> WC: should use the stored mtime, or (if none defined) use current
> time.
This is effectively a checkout, so it should use the current mtime for
the property value, but since it is a copy, that will be overruled at
commit time with the current time.
> > Philip Martin comments:
> > "Even if the merge effectively causes local mods to disappear?
> >
> > $ svn merge -cN
> > $ svn merge -c-N
> >
> > What about a the merge only affects the MTIME_RECORD property -- should
> > such a merge update the mtime, update the property and so make the
> > item committable?"
> ...
> > Philip Martin comments:
> > "What happens if the user provokes an MTIME_RECORD property conflict?"
> >
> > Hmm. I hadn't thought about that one. Since the proposal actually only
> > is about recording mtimes, the actual value in a working copy with
> > lots of mods may not be as important as the value in a clean and new
> > working copy. Conflicts are not really relevant to this property:
> > anybody who changes the property will cause a commit which overwrites
> > the value with the latest found in the working copy. Thereby, I think
> > we should ignore conflicts and pick the working copy value as the
> > 'right' one.
> How about this idea - when we find a conflict for this property, we simply
> take the newer timestamp?
> And when we merge data, we take the current timestamp - as this is when the
> merge happened?
Well, in my original idea, there is no need to do that: if you commit,
it takes the current mtime anyway, so, there's no reason to conflict
for the property either for merging or for updating....
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 23:01:24 2006