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. 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.
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.
WC -> REPOS: should take the current mtime of the item?
REPOS -> WC: should use the stored mtime, or (if none defined) use 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?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 9 07:01:53 2006