[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: editor v2 and replace

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Sat, 13 Jun 2009 14:46:23 -0400

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
working copy...

   $ 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
sides.

Is that too hand-wavy to be meaningful? Do you see what I'm getting at?
(Or is this already taken for granted?)

-Karl

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361851
Received on 2009-06-13 20:46:44 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.