My mixed revision working copy remains after a 'svn update'

[webste...@rogers.com]

My mixed revision working copy remains mixed revision after multiple attempts with 'svn update'.

Here's the final status output:

[linux] >> svn st -u
X                    vobs/common/cpCommon
X                    vobs/common/dclCommon
X                    vobs/ots/broadcom/BCM_SDK_6.4.11
X                    vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API
X                    vobs/ots/osm4/Target/PldImages/lim400g_1
X                    vobs/ots/osm4/Tests/framework/tl1probe/mteraiv
X                    vobs/ots/uboot/u-boot-2009.06
X                    vobs/ots/uboot/u-boot-2013.01.01
X                    vobs/ots/wrlplat/tlab_qemuppc
X                    vobs/ots/wrlplat/tlab_xeoncore50
X                    vobs/ots/wrlplat/tlabqoriq50_small
X                    vobs/prod
Status against revision:  13673

Performing status on external item at 'vobs/ots/osm4/Target/PldImages/lim400g_1':
Status against revision:  87468

Performing status on external item at 'vobs/ots/uboot/u-boot-2009.06':
Status against revision:    475

Performing status on external item at 'vobs/common/cpCommon':
Status against revision:    101

Performing status on external item at 'vobs/common/dclCommon':
Status against revision:    101

Performing status on external item at 'vobs/ots/uboot/u-boot-2013.01.01':
Status against revision:    475

Performing status on external item at 'vobs/ots/wrlplat/tlab_xeoncore50':
Status against revision:    539

Performing status on external item at 'vobs/prod':
Status against revision:   1290

Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6.4.11':
Status against revision:    614

Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv':
X                    vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library
Status against revision:   2575

Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library':
Status against revision:  65663

Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_small':
Status against revision:    672

Performing status on external item at 'vobs/ots/wrlplat/tlab_qemuppc':
Status against revision:    403

Performing status on external item at 'vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API':
Status against revision:  73002

[Linux] >> svnversion
475:13673S

There are two 'uboot' svn:externals pegged at 475 so I deleted the parent directory (i.e. rm -rf vobs/ots/uboot) and did another 'svn update' but that didn't clean it up.  The svnversion is still reporting 475:13673S.

The svn client version is 1.8.14.

Thanks in advance for any insights.

Brent

---- Brent

[Ryan Schmidt]

Presumably, those externals were deliberately pegged to those revisions, so this is behaving as intended. If you want those externals to point to newer versions, change the revision in the svn:externals property, then svn update again.

[webste...@rogers.com]

Yes, these externals are deliberately pegged and I have other working copies(WC) based on the exact same checkout and they show up as a single and not a mixed revision WC.

Of the 108 WCs I've looked at, 36 are in a mixed-revision configuration and that's OK but in several cases, these WCs cannot be updated back to a single revision configuration. As well, the svnversion command is indicating that these WCs are 'Switched' but that has not been the case, they have never been switched.

At this point, I'm recommending to my users to delete any WC that cannot by configured back into a single revision WC.

Comments, suggestions, recommendations would be great.

 

---- Brent

---

From: Ryan Schmidt <subvers...@ryandesign.com>
To: webste...@rogers.com
Cc: Subversion Users <us...@subversion.apache.org>
Sent: Wednesday, August 17, 2016 12:49 AM
Subject: Re: My mixed revision working copy remains after a 'svn update'

[Johan Corveleyn]

On Thu, Aug 18, 2016 at 9:33 PM, <webste...@rogers.com> wrote:
> Yes, these externals are deliberately pegged and I have other working
> copies(WC) based on the exact same checkout and they show up as a single and
> not a mixed revision WC.
>
> Of the 108 WCs I've looked at, 36 are in a mixed-revision configuration and
> that's OK but in several cases, these WCs cannot be updated back to a single
> revision configuration. As well, the svnversion command is indicating that
> these WCs are 'Switched' but that has not been the case, they have never
> been switched.
>
> At this point, I'm recommending to my users to delete any WC that cannot by
> configured back into a single revision WC.
>
> Comments, suggestions, recommendations would be great.

Okay, let's take another look at your initial problem description:

About your directory deletion: just deleting the vobs/ots/uboot
directory from disk will not change anything, because you're only
deleting local file data, not changing any of the svn metadata
(including the svn:externals definitions), which are contained in your
wcroot/.svn directory. To really get rid of those vobs/ots/uboot
externals you should remove their definition from the relevant
svn:externals property, and run another 'svn update'.

Now, what strikes me as odd: svnversion reports 475:13673S, and you
have two vobs/ots/uboot directories which seem to be configured at
that revision (output of 'svn st -u' talks about "Status against
revision: 475"). But for vobs/common/cpCommon and
vobs/common/dclCommon status reports "Status against revision:
101". So why doesn't svnversion say 101:13673S? What's special about
the externals definitions of the vobs/ots/uboot dirs, compared to the
vobs/common/* dirs? Are they configured differently?

Something else to try: install a 1.9.4 svn client and see what it does
with that same working copy. What does it report? Is it able to
restore your desired single-revisionness after an 'svn update'?

--
Johan

[webste...@rogers.com]

As an amendment, I created one more WC with my 1.8.16 svn client at the original XXX revision. (i.e. prior to the directory deletion and subsequent addition of the svn:externals).  I then updated the client to 1.9.4 and ran the 'svn update' where it successfully deleted the directory and then added the svn:externals to overlay the same directory name from another repository.  When I ran 'svnversion', it reported back a single revision and not Switched. -- It worked!!!!

So I have a solution, if my users haven't already done a 'svn update' with the older 1.8.xx client.  But is there anyway to fix an already updated WC with the svnversion command reports it as a switched mix revision WC?

 

---- Brent

---

From: Brent Webster <bedu...@gmail.com>
To: subversion-users <subversi...@googlegroups.com>
Cc: us...@subversion.apache.org; webste...@rogers.com
Sent: Thursday, September 1, 2016 1:58 PM
Subject: Re: My mixed revision working copy remains after a 'svn update'

I was able to reproduce the problem.

When we migrated from Clearcase to SVN, all the separate VOBs that made up our product (as well as several other products) were copied into one large repository.  The other products are now migrating from Clearcase so we need to emulate some of the common VOB directory structure by moving the contents of these common directories into separate repositories and then use svn:externals across these multiple products to include this common code back into each product.

The problem is the original large repository where we need to delete the contents of these common directories and then add svn:externals to reference the new common code from these other repositories.

The scenarios:
I have three working copies(WCs): ws0, ws1 and ws2 that are all checked out from the same branch/revision:

1/ ws0 is where I will perform the deletion of the broadcom 6.3.5 directory, commit it and then add the svn:externals as a 2nd commit.
    Note: If we deleted the directory and then defined the svn:externals with the same name as one commit, it resulted in directory tree conflicts.
    e.g.
        rev XXX is the original revision, XXX+1 is the deletion of the broadcom directory and XXX+2 is the definition of the svn:externals
    When I run the 'svnversion' command, it reports back a single revision: XXX+2

2/  So ws1 is at revision XXX and 'svn update -r XXX+1' that deletes the broadcom directory and updates the WC successfully.
     Then a second 'svn update' is run that creates the new svn:externals of the same name as the broadcom directory
     When I run the 'svnversion' command, it reports back a single revision: XXX+2

3/ So ws2 is at revision XXX and a 'svn update' will do both the delete of the existing broadcom directory and then create the new
    svn:externals of the same name as the broadcom directory.  It fails with the following warning:
          svn: warning: W155009: Failed to run the WC DB work queue associated with '/home/bwebste1/svn/ws2/broadcom/BCM_SDK_6.3.5', work item 1 (file-install broadcom/BCM_SDK_6.3.5/sdk-all/systems/linux/user/groove-2_6/Makefile 1 0 1 1)
 
          Updated to revision 14012.
          svn: E205011: Failure occurred processing one or more externals definitions
  
     Running 'svnversion' reports back a switched mixed revision WC
     i.e. 285:14012S
          where 285 is the pegged revision of the new svn:externals and 14012 is the XXX+2 revision of this product's repository.

     When I run a subsequent 'svn update', it reports the following:
          Updating '.':

          Fetching external item into 'broadcom/BCM_SDK_6.3.5':
          svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted

          At revision 14012.
          svn: E205011: Failure occurred processing one or more externals definitions

Running 'svn cleanup' or 'svn cleanup --include-externals' has no affect.
I then upgraded my svn client from 1.8.16 to 1.9.4 but no change either.
The 'svnversion' still reports the workspace as a Switched mixed revision WC.

At this point, I can only recommend the following: 
     If the designer does not require to execute the 'svn merge' command then this WC is OK for use else delete it and create a new WC.

Any better solutions?.

Performing status on external item at 'vobs/ots/wrlplat/tlab_ xeoncore50':

Status against revision:    539

Performing status on external item at 'vobs/prod':
Status against revision:   1290

Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6. 4.11':
Status against revision:    614

Performing status on external item at 'vobs/ots/osm4/Tests/ framework/tl1probe/mteraiv':
X                    vobs/ots/osm4/Tests/framework/ tl1probe/mteraiv/TL1_Library
Status against revision:   2575

Performing status on external item at 'vobs/ots/osm4/Tests/ framework/tl1probe/mteraiv/ TL1_Library':
Status against revision:  65663

Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_ small':
Status against revision:    672

Performing status on external item at 'vobs/ots/wrlplat/tlab_ qemuppc':
Status against revision:    403

Performing status on external item at 'vobs/ots/osm4/Apps/HalServer/ Drivers/lim400/Lim400API':
Status against revision:  73002

[Linux] >> svnversion
475:13673S

[Brent Webster]