Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: error (nike.apache.org: local policy)
From: John Maher <JohnM@rotair.com>
To: Edwin Castro <0ptikGhost@gmx.us>, "users@subversion.apache.org"
	<users@subversion.apache.org>
Subject: RE: Switching
Thread-Topic: Switching
Thread-Index: 
 Ac6dAeCmrpSdVW6lT1iVVIVXpXzUJwAp+KnAAAYozyAABiV0sAAB4KjQAGHSBAAABPsYgAAH1tqw
Date: Thu, 22 Aug 2013 17:43:21 +0000
Message-ID: <910250F21FAA2A4E8F72DD21EA7807660906CF26@VMJudi.corp.rotair.com>
References: <910250F21FAA2A4E8F72DD21EA7807660906148C@VMJudi.corp.rotair.com>
 <1B05D8F50421E24799AE93B03CC284BE01CAE9CCEB@CRPMBX01.corp.cbeyond.net>
 <910250F21FAA2A4E8F72DD21EA78076609065B00@VMJudi.corp.rotair.com>
 <1B05D8F50421E24799AE93B03CC284BE01CAFDB285@CRPMBX01.corp.cbeyond.net>
 <910250F21FAA2A4E8F72DD21EA78076609066DB2@VMJudi.corp.rotair.com>
 <CAOAgVpwr_8BPxjTDkV4BbgST4RuDP9Ek5+rWusqkCAGWcSLD-Q@mail.gmail.com>
 <521648D3.7070308@gmx.us>
In-Reply-To: <521648D3.7070308@gmx.us>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks for the reply Edwin.

The clean up script is a good idea but won't work here.  We have mostly all=
 class libraries.  One executable.  This means to test we need to specify a=
n application in the project.  Some developers use the exe while some use a=
 tool made just for testing the classes.  This information is in the *.sou =
files which are unversioned for this reason.  So we don't want to delete th=
em (as I incorrectly stated somewhere) but ignore them.

I'll try the force, that may work.  I'll try it on a copy of the repository=
.

JM

-----Original Message-----
From: Edwin Castro [mailto:0ptikGhost@gmx.us]=20
Sent: Thursday, August 22, 2013 1:22 PM
To: users@subversion.apache.org
Subject: Re: Switching

On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher <JohnM@rotair.com> wrote:
>> >
>> > @Andrew there is no need for a svn copy.  I do not want to copy a feat=
ure in one branch to another; I wish to keep the code isolated.
>> >
>> > And yes I know subversion won't delete unversioned files, I appreciate=
 the info on how subversion works.  Some of it was helpful.  I was hoping t=
o hear how others may have solved the same problem.
> Your problem is not so much that svn doesn't deleted the unversioned=20
> files, but that it can't delete the directory containing them.
>
>> > But it seems the only answer is a tedious and manual process for the s=
implest of enhancements.
> Don't your build tools have commands to remove any spurious files=20
> they've created or some equivalent of 'make clean' that you can run to=20
> remove the clutter in a non-tedious way so that svn switch is free to=20
> work correctly with the versioned content?
>

I typically run into this problem when a "build output" directory exists du=
e to having built the project that doesn't exist in the other branch.
Something along these lines:

root/
+-- projectA/
|   +-- bin/
|   |   +-- debug/
|   |   |   +-- projectA.dll
|   |   +-- release/
|   |       +-- projectA.dll
|   +-- src/
+-- projectB/
    +-- bin/
    |   +-- debug/
    |   |   +-- projectB.dll
    |   +-- release/
    |       +-- projectB.dll
    +-- src/

Let's say in branch1 both projects exist but in branch2 only projectB exist=
s. The tree above would obviously imply I am currently on branch1.
I would have added the bin directory to svn:ignore on both the projectA and=
 projectB directories as I don't want to accidentally commit the contents o=
f the bin directory. The tree above is only an example. The branches I'm us=
ed to dealing with contain hundreds of such projects and building all of th=
em can take up to 2 hours even on relatively fast hardware.

If projectA has been built while I'm working on branch1 and I want to svn s=
witch to branch2, then svn will attempt to delete root/projectA/ but it can=
't because root/projectA/bin/ still exists. The switch leaves behind root/p=
rojectA/ as unversioned (including the root/projectA/bin/ directory). Now t=
hat I'm done working with branch2 I try to svn switch back to branch1 and s=
vn fails to add root/projectA/ because it already exists in the working cop=
y unversioned.

We have a root build script that can run the clean target on all of our pro=
jects. Alternatively, I could run clean on individual projects prior to a s=
witch but that requires that I know which projects do not exist on the targ=
et branch. I could also use the --force argument to svn switch but it carri=
es it's own hazards. From svn help switch:

     If --force is used, unversioned obstructing paths in the working
     copy do not automatically cause a failure if the switch attempts to
     add the same path.  If the obstructing path is the same type (file
     or directory) as the corresponding path in the repository it becomes
     versioned but its contents are left 'as-is' in the working copy.
     This means that an obstructing directory's unversioned children may
     also obstruct and become versioned.  For files, any content difference=
s
     between the obstruction and the repository are treated like a local
     modification to the working copy.  All properties from the repository
     are applied to the obstructing path.

I'm particularly worried by "This means that an obstructing directory's unv=
ersioned children may also obstruct and become versioned." You might end up=
 committing files you don't want to commit by using svn switch --force so y=
ou'll want to be very careful. It would probably be a good idea to follow u=
p svn switch --force with svn status to see if anything becomes versioned t=
hat shouldn't be.

Even though our builds can be quite long, I typically find it much safer to=
 simply clean all of the projects prior to performing svn switch. I typical=
ly don't use our root build script to clean the projects because it takes a=
 long time loading up all of those different projects/solutions to run the =
clean target. Since I'm on Windows I use PowerShell to find all ignored and=
 unversioned items and manually delete
them:

svn status --no-ignore --ignore-externals | Where-Object { $_ -match '^[I?]=
' } | Remove-Item -Force -Recurse -Path { $_.Substring(8) } -Verbose

I've needed to update the substring index in the past because a new svn rel=
ease changed the svn status format on me.

Performing this kind of cleanup allowed svn switch to work correctly every =
time. Then again, this does imply that every thing must be rebuilt post swi=
tch which can be very painful when you have as many projects as we do. If s=
ome of the ignored/unversioned files are user files that should not be vers=
ioned, then cleaning like this creates additional problems. We've worked ar=
ound these problems by requiring that user files are not used and adding a =
target to our root build script which can fetch build output from our CI se=
rver.

With as many as 15+ active branches at any one time, each with hundreds of =
projects, it is difficult to copy around user files whenever a new branch i=
s created. Sometimes those files need to be kept in sync as merging occurs =
creating additional synching headaches. We found it much easier to avoid us=
er files instead of managing their contents manually.

Most of our developers use a working copy per branch and avoid switch altog=
ether but only because the guidelines they follow told them so.
Even then, rebuilding the entire tree took enough time that we wanted to av=
oid it so we grab the latest build output from the appropriate CI build (we=
 have one per branch) as an optimization. We found rebuilding only the proj=
ects we are currently working on is much simpler and faster than building t=
he entire tree even when we don't use svn switch.

Of course, given that we've built processes and tools to avoid building the=
 entire tree we made it possible to use svn switch even though most people =
here don't use it. We even added a target to our root build script cleans e=
verything so that developers do not have to remember the magic PowerShell i=
ncantation required. The guidelines written many years ago tell them not to=
 trust/use svn switch so they don't use it.

I use svn switch quite successfully and switch between 5-6 branches on a da=
ily basis but I do have access to tools that help me succeed, specifically =
our clean script and the ability to download pre-built output from our CI s=
erver.

--
Edwin G. Castro