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

2016-09-01 Thread webster.brent 
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 
 To: subversion-users  
Cc: users@subversion.apache.org; webster.br...@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?.


On Tuesday, August 16, 2016 at 3:55:41 PM UTC-4, webste...@rogers.com wrote:
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/wr

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

2016-09-01 Thread Brent Webster 
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?.


On Tuesday, August 16, 2016 at 3:55:41 PM UTC-4, webste...@rogers.com wrote:
>
> My mixed revision working copy remains mixed revision after multiple 
> attempts with 'svn update'.
> Here's the final status output:
>
> [linux] >> svn st -u
> Xvobs/common/cpCommon
> Xvobs/common/dclCommon
> Xvobs/ots/broadcom/BCM_SDK_6.4.11
> Xvobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API
> Xvobs/ots/osm4/Target/PldImages/lim400g_1
> Xvobs/ots/osm4/Tests/framework/tl1probe/mteraiv
> Xvobs/ots/uboot/u-boot-2009.06
> Xvobs/ots/uboot/u-boot-2013.01.01
> Xvobs/ots/wrlplat/tlab_qemuppc
> Xvobs/ots/wrlplat/tlab_xeoncore50
> Xvobs/ots/wrlplat/tlabqoriq50_small
> Xvobs/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':
> Stat

SVN Feature Request: Selecting the revision for pinning externals

2016-09-01 Thread Israel Sadeh 
Hi,

The new '-pin-externals' switch of the 'svn copy' command pins the externals to 
their latest version.
This makes sense when copying the latest revision, but in case the copied 
branch is from an older revision, it also makes sense to pin the externals to 
the old revision.
This way in case it will be possible to create a tag from an old revision, and 
not only from the latest one.

My suggestion:  Add an optional pinning-revision parameter to the 
'-pin-externals' switch.
By default (if the pinning-revision' parameter isn't set)  - the externals will 
be pinned to the latest version.
If the parameter is set - the externals will be pinned to the parameter 
revision.
Best regards,

Israel Sadeh

[Description: Description: logo]

Israel Sadeh
Software Engineer
RTC Vision Ltd.
www.rtc-vision.com