Page 2 of 2 FirstFirst 1 2
Results 11 to 14 of 14

Thread: Parallelize up-to-dateness check during svn update

  1. #11
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    10,820

    Default

    Bumping back to first page.

    If it doesn't work with SimpleSvnUpdate == false, we should eliminate the setting and always do the "true" behavior, as xKiv suggests.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  2. #12
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    10,820

    Default

    I see the following comment in front of WCAtHead:

    Code:
    	/**
    	 * For users who just want "simple" update behavior, check if the revision of the project root and the repo root are
    	 * the same.
    	 * <p>
    	 * Users who have used <code>svn switch</code> on some of their project should not use this.
    	 * 
    	 * @param f the working copy
    	 * @param quiet if <code>true</code>, suppresses RequestLogger output.
    	 * @param runnables if present, enables multi-threaded behaviour, and adds a runnable to the list; otherwise executes the runnable
    	 * @return <code>true</code> if the working copy is at HEAD, or runnable was successfully added to <code>runnables</code> 
    	 */
    I have no idea what "svn switch" does or how somebody who has used it would know to go and change the value of the setting from true to false.

    Code:
    global	simpleSvnUpdate	true
    Which is to say, change from the default value.

    We do let you configure it via the GUI in the SVN Panel of Preferences.

    Code:
    			tip = "<html>\"Simple\" behavior means that svn will just check the revision of your project's<br>"
    				+ "root directory and compare it to that of the root directory in the repo.<br>" + "<br>"
    				+ "This saves time and server hits over a full <i>svn update</i>, but advanced users with<br>"
    				+ "mixed-revision working copies or the like may want to turn it off so that<br>"
    				+ "a full <i>svn update</i> happens every time.</html>";
    			this.queue( new PreferenceCheckBox(
    				"simpleSvnUpdate", "Use simple SVN update behavior for faster updates", tip ) );
    Apparently, somebody lost knows chose to disable it - and the new parallelized update behavior doesn't support it.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  3. #13
    Senior Member
    Join Date
    Apr 2009
    Posts
    1,649

    Default

    svn switch is for "relocating" the remote repository url - i.e. if you have a script at, say, https://svn.code.sf.net/p/user/script/code which stops working, but you know that there's a working fork over at https://svn.user.great.cloud.org/code/script
    the problem with that is that the fork doesn't need to have the same revision history, so revision numbers are useless for testing if you are up-to-head
    but honestly, if you svn switch to somewhere that isn't an exact duplicate, you shouldn't be surprised when everything breaks.


    Mixed revisions are a different thing, and dangerous for a different reason. It's possible to get those in two ways. One is relatively benign - you update (to HEAD) only parts of the WC. This means that the WC root is "stuck" on an older revision number, but only until the next update. Once you check the WC root's revision against the remote server, you will find that the remote has a newer revision (and mafia will do a full update).

    The other is worse - you update part (file or directory) of the WC to an *earlier* revision. It is then *pinned* to that particular revision, and doesn't update. And different parts can be pinned to different revisions. And you can nest an "updated to HEAD" part within a pinned subdirectory.
    I don't think this shouldn't be a problem here either, though, unless you somehow (manually) update the root to current HEAD but also leave some files/subdirectories *not* updated (and also not pinned). This is possible, but requires the user to be a bastard from hell. And if you tell svn to only update first two subdirectory levels, you should expect the third level to not update.

  4. #14

    Default

    17545 removes simpleSvnUpdate.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •