On Tue, Mar 12, 2013 at 3:48 PM, Philip Martin <[email protected]>wrote:
> Bert Huijben <[email protected]> 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/
