Greg Stein <gstein_at_gmail.com> writes:
> Hmm. I figured that with the "add follows" flag, then you could know
> to avoid dual-notifications, and just wait for the add. But yah...
> then you'd need to remember (at add time) that a delete had happened.
> More cross-call state.
> Adding a flag to the add calls should work. Tho I hate the "replace"
> terminology. Maybe "overwrite=TRUE" is better? (and, of course,
> failure if you're trying to overwrite, and nothing is there)
> Bikeshed. But yah. Extending the add calls sounds better. Thanks!
I know I'm sort of chiming in from the late Jurassic here, but:
While +1 on 'replace' as a single operation in editor v2, I think it's
important that the editor call sequence match up the working-copy
metadata. In other words, if someone replaces 'foo' with 'bar' in their
$ svn rm foo
$ svn mv bar foo
...then the working copy (v2) metadata should clearly indicate on both
sides that it's a replacement, and when the editor call happens, it
should record (also on both sides) that the local state has now been
"satisfied" by the editor.
This could be a little tricky, because you don't know which side you'll
encounter first in a commit or update crawl. I guess what I'm saying
is, encountering either side should be like encountering both, as far as
the working copy is concerned: the single editor call should update both
Is that too hand-wavy to be meaningful? Do you see what I'm getting at?
(Or is this already taken for granted?)
Received on 2009-06-13 20:46:44 CEST