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

workaround for synchronize after checkout

From: Eugene Kuleshov <eu_at_md.pp.ru>
Date: 2005-08-22 04:10:52 CEST

Mark,

  I've put together some prototype for the approach we have discussed
for AbstractJhlClientAdapter. Basically it is what user would do
manually. See patch attached.

  Current limitations are all your edge cases, some logging in DirUtils
and progress indication for DirUtils functions.
  Present code also always using copy + delete in place of rename().

  If you ok with doing something like this I can pull up methods to
handle temp location to common adapter class (to make it work for
cmdAdapter) and check what should be done in the UI.

  regards,
  Eugene

>I still think you should wait until we know if Subversion is going to
>address it. If you want to tackle it, and have me do something, then come
>up with a more specific design. I would ideally like to see this done
>without any new UI, the same way Subversion would do it. What you
>describe sounds confusing and complicated for the user.
>
>At a high-level, what I think needs to be done is this:
>
>1) Move existing project to TEMP
>2) Checkout project
>3) Copy existing project on top of checked out project (this might mean
>copying files individually)
>4) Run svn cleanup to fix the stored timestamps for files that are
>unchanged
>
>You probably have to do some of this without Eclipse knowing about it.
>
>I do not think you need to do compares or any of that stuff. The user can
>always use revert to undo changes they did not want. Of course they can
>also do a compare to see what they changed. Likewise, commit will just
>pick up the real changes itself and the existing wizard will already
>launch the commit dialog at the end.
>
>My concerns are still the edge cases:
>
>1) Line endings might not be correct
>2) keywords might not be expanded correctly. Would this cause incorrect
>diffs?
>3) svn:needs-lock and read-only attribute might not be correct
>
>Personally, I think that documenting the manual steps, making the UI
>reflect what we are able to do, and modify when Subversion can do this, is
>the better approach. You are free to work on this, and I will help you as
>best I can.
>
>

Index: C:/dev/eclipse/svnClientAdapter/src/main/org/tigris/subversion/svnclientadapter/javahl/AbstractJhlClientAdapter.java
===================================================================
--- C:/dev/eclipse/svnClientAdapter/src/main/org/tigris/subversion/svnclientadapter/javahl/AbstractJhlClientAdapter.java (revision 1564)
+++ C:/dev/eclipse/svnClientAdapter/src/main/org/tigris/subversion/svnclientadapter/javahl/AbstractJhlClientAdapter.java (working copy)
@@ -199,6 +199,19 @@
         SVNRevision revision,
         boolean recurse)
         throws SVNClientException {
+
+ File tempDir = null;
+ try {
+ if(!DirUtils.isDirEmpty(destPath)) {
+ tempDir = DirUtils.createTempDir();
+ DirUtils.copyDir(destPath, tempDir);
+ DirUtils.delete(destPath);
+ }
+ } catch( IOException e) {
+ notificationHandler.logException(e);
+ throw new SVNClientException(e);
+ }
+
         try {
             notificationHandler.setCommand(ISVNNotifyListener.Command.CHECKOUT);
             notificationHandler.logCommandLine(
@@ -216,6 +229,17 @@
             notificationHandler.logException(e);
             throw new SVNClientException(e);
         }
+
+ try {
+ if(tempDir!=null) {
+ DirUtils.copyDir(tempDir, destPath);
+ cleanup(destPath);
+ DirUtils.delete(tempDir);
+ }
+ } catch( IOException e) {
+ notificationHandler.logException(e);
+ throw new SVNClientException(e);
+ }
     }
 
     /**
Received on Mon Aug 22 12:10:52 2005

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