On Tue, Mar 12, 2013 at 3:48 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> Bert Huijben <bert_at_qqmail.nl> writes:
>
> > To an api user that is halfway through a refactoring, you can’t say: you
> > can’t move this file directory. Go undo everything you did before.
>
> Not undo, run update. If update brings in no changes and just bumps
> revisions it is a trivial operation. Is that not possible? If update
> brings in real changes then the user has to do that before committing.
> Isn't it better to do it before the move rather than after the move?
>
> > For ‘svn’ a move is a single operation that may fail with some warning,
> but
> > to an aplication that uses our library (TortoiseSvn, Eclipse, AnkhSVN) a
> > move is a small operation inside a larger scope.
> >
> > For these clients just saying a move might or might not work is breaking
> > compatibility with Subversion 1.0-1.7. They prefer the copy behavior
> over a
> > broken working copy, as that doesn’t break the external refactoring tool
> > that they wrap. (They just record operations. They can’t alter what to do
> > based on a later error)
> >
> > Making mixed revision moves work properly is of course the real prefered
> > solution, but if we postpone that to a future version this is the next
> best
> > thing we can do.
> >
> > The api version of ‘svn mv A B’ should have the same behavior as in
> > 1.0-1.6. Tracking moves where we can is nice to our users and better then
> > always requiring copy+delete for these tools.
>
> It still doesn't make sense to me.
>
> When we changed merge to check for a single revision working copy did
> all the GUIs hard-code --force and bypass the check? I can see that a
> GUI might give users the option but you seem to be saying that GUIs need
> to disable the check altogether.
The difference is that IDE users are typically not taking an option named
"svn move", as they are when they run merge. If that was the only scenario
we had to support, then I would not be that concerned.
In IDE's there are a lot of things that can trigger moves. I gave example
of drag and drop as well as refactor. In a lot of IDE's this will also
involve changes to source code. For example, if I move a Java class, the
contents of the source code for that class as well as all of the other
classes that use it will be updated by the IDE to point to the new
location. In these cases, in Eclipse, we can block the operation if it
fails and Eclipse will undo what it has already done. The process is not
always pretty but it often does work. When it does not work well is when
the operation triggers more than one move and it fails during the middle of
the process. For example, if I rename a Java package, that is just a
folder rename. Unfortunately, in some cases, instead of just telling us to
rename the folder, Eclipse will often tell us to to move each of the files
in the folder instead. This is a case, where failures in the middle of the
process do not undo well. I would not expect this particular error to
occur in the middle of the process though. It feels like an all or nothing
thing.
As an aside, even before SVN 1.7, I turned merge into a wizard that
included "best practices" checks. One of these was warning you if working
copy was mixed revisions. So SVN 1.7 was not an issue for me in this
regard. I am bringing this up because it would be nice if JavaHL had some
API's we could call to tell us things like:
Is working copy mixed revision?
Are there any switched folders?
Etc. We implement these things ourselves today using status and other API.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-03-12 21:03:59 CET