Switching

[John Maher <Jo...@rotair.com>]

Hello,

I want to thank all who have been helpful.  I have gotten my test project to merge branches successfully.  Now I am trying it on our production code and wish to make sure I am not making any mistakes.

I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory.   I have created two branches for two new features.  One feature extends an existing library.  The other feature adds a new library as well as extending an existing one.  When I switch I create a conflict because the directory exists in one branch and not the other:

local unversioned, incoming add upon switch

This may or may not be what is supposed to happen, that would be the first thing I would like to know.  How to fix it would be the second thing that I would like to know.  According to the help of the resolve command says:

So I tried svn resolve -accept working LibraryDirectory but I believe that was a mistake because then the directory was marked "Delete" which is not what I wanted.  Does anyone know what is the proper response?

I did not want to lose the library from the working copy so I switched back to the other branch and then switch back.  Now it says:

local delete, incoming delete upon switch

It seems I did something wrong.  My next step would be to add the library back, but that may not be the best response.  Any suggestions?


Thanks
JM

Re: Switching

[Edwin Castro <0p...@gmx.us>]

I agree with Les here on the point about making sure you can automate
the process correctly only with versioned resources. In our CI builds we
have the versioned resources configured so that all tests are executed
every time. Developers execute subsets of tests through their tools and
are expected to manage their tools on their own.

Sounds like there might be a trade off between copying/reconfiguring if
they choose one working copy per branch and reconfiguring if they
clean/switch between branches. That might be best left as an individual
developer decision.

On 8/22/13 10:58 AM, John Maher wrote:
> You are correct that there will be issues with a fresh checkout.  But I can live with that.  The code will not be affected, just the way the code is tested.  Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it.
>
> Think config or settings file.
>
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com] 
> Sent: Thursday, August 22, 2013 1:53 PM
> To: John Maher
> Cc: Edwin Castro; users@subversion.apache.org
> Subject: Re: Switching
>
> On Thu, Aug 22, 2013 at 12:43 PM, John Maher <Jo...@rotair.com> wrote:
>> 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 an 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 them (as I incorrectly stated somewhere) but ignore them.
> You are sort-of asking for trouble if you have any dependency on unversioned files being in a workspace at all, much less for them to continue to exist when switching among versions with/without the
> containing directories.   I'd advise stepping back from the immediate
> problem and thinking of processes that will always work with a fresh checkout so that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host.  It will simply your life even for manual operations if you can count on that.
>

RE: Switching

[John Maher <Jo...@rotair.com>]

Good to know, thank you.


-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de] 
Sent: Friday, August 23, 2013 12:50 PM
To: Edwin Castro
Cc: users@subversion.apache.org
Subject: Re: Switching

On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote:
> I think the mailing list has already said the *best* way to use switch 
> is to have a clean working copy (clean out all ignored and unversioned 
> files which is admittedly inconvenient).

This won't help right now, but cleaning out such items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote:
> I think the mailing list has already said the *best* way to use switch
> is to have a clean working copy (clean out all ignored and unversioned
> files which is admittedly inconvenient).

This won't help right now, but cleaning out such items will be easier
in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/22/13 3:00 PM, Les Mikesell wrote:
>> Why can svn not, instead, simply interpret an already existing directory
>> > as not a conflict? Certainly if a versioned file would overwrite an
>> > unversioned file of the same name then that is a true conflict because
>> > the content may differ. A directory has nicely compartmentalized units
>> > of content which can be handled in a smarter way.
> No, look at your logs of directory history.  They aren't just
> containers for whatever happens to be there, the history of adds and
> deletes are there.   It might be possible to make things work where it
> would pretend that it created a directory keeping the history from the
> repo but ignoring extraneous content, but its not what I'd expect.

Directories also have "content" in the form of properties.

The problem is svn doesn't have enough information to make *good*
decisions about conflicts between two objects with different histories
(regardless of whether the object is a file, directory, or other). Here
are some examples:

1.) Two objects added in two different branches have different
histories, even if they have the same name and content, causing a tree
conflict on merge.

2.) Two objects with the same name where one is versioned (has history)
and the other is unversioned (no history) also causes a tree conflict on
merge/update/switch/etc.

Because a good decision cannot be made, svn punts and requires the user
to take action.

--
Edwin G. Castro

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown <tr...@travisbrown.ca> wrote:
> On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
> <snip>
>>The contents of the file are irrelevant.  The point is that it has to
>>either be versioned so svn can delete it knowing that you can get it
>>back, and then delete the containing directory that is really the
>>issue, or you have to delete it yourself.  Pick one.  If it really is
> <snip>
>
> Why must svn delete the directory in order to create it?

When it creates it, it will create it as a versioned object with
history.  What is it supposed to do with that history when it can't
create it because there is already an unversioned instance there?
Svn doesn't pretend that things that just happen to have the same
names are the same object, they actually have to have the same
history.

> Reading this thread it seems to me that the core of the issue is that svn
> switch is not symmetrical when dealing with directories.

I think it would have the same problem with any unversioned object
with the same name as the versioned one that it needs to create.

> Why can svn not, instead, simply interpret an already existing directory
> as not a conflict? Certainly if a versioned file would overwrite an
> unversioned file of the same name then that is a true conflict because
> the content may differ. A directory has nicely compartmentalized units
> of content which can be handled in a smarter way.

No, look at your logs of directory history.  They aren't just
containers for whatever happens to be there, the history of adds and
deletes are there.   It might be possible to make things work where it
would pretend that it created a directory keeping the history from the
repo but ignoring extraneous content, but its not what I'd expect.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
<snip>
>The contents of the file are irrelevant.  The point is that it has to
>either be versioned so svn can delete it knowing that you can get it
>back, and then delete the containing directory that is really the
>issue, or you have to delete it yourself.  Pick one.  If it really is
<snip>

Why must svn delete the directory in order to create it?

Reading this thread it seems to me that the core of the issue is that svn
switch is not symmetrical when dealing with directories. When switching
away from a branch with an extra directory which contains unversioned
files, svn leaves the directory. However, when switching back to the
branch with the extra directory it requires that no such directory
already exist, even if none of the incoming files have conflicting
unversioned twins.

Why can svn not, instead, simply interpret an already existing directory
as not a conflict? Certainly if a versioned file would overwrite an
unversioned file of the same name then that is a true conflict because
the content may differ. A directory has nicely compartmentalized units
of content which can be handled in a smarter way.

>
>-- 
>   Les Mikesell
>     lesmikesell@gmail.com

-- 
Travis

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/23/13 7:43 AM, John Maher wrote:
> The question is can I bring back my working directory from a failed switch (I'm talking undo, not resolve) so I can use the force option or must I always use the force option to be able to switch branches?

I think the mailing list has already said the *best* way to use switch
is to have a clean working copy (clean out all ignored and unversioned
files which is admittedly inconvenient). Some offered the opinion that
the best way to use switch was to not use it at all.

One way to bring back your working directory from a failed switch is to
delete the conflicted directory and then svn update. If your entire
working copy is "failed" then you'd need to delete the working copy and
checkout again.

I suppose you could try switching back to a branch that doesn't contain
the directory in question, clean up, and then switch back.

Use --force with caution. According to the documentation it can
accidentally version previously unversioned files.

--
Edwin G. Castro

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/23/13 7:43 AM, John Maher wrote:
> The files in question are settings files (think config files) and intermediate compilet generated files.  The settings files can be recreated at any time.  If they are wrong the only thing affected is the development environment.  The other files get recreated every time the code is run, plus they never get into production.  So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway.  Don't read more than what is stated otherwise you have a chance of being wrong and wasting time.

When these files get in the way of subversion performing an operation,
then the sensible thing to do is to delete them. I think I heard many
people voice this opinion on this mailing list. If their contents should
be kept around then they should be versioned. That opinion was also
voiced by the mailing list.

--
Edwin G. Castro

RE: Switching

[John Maher <Jo...@rotair.com>]

I will try to explain one more time.  The files in question are settings files (think config files) and intermediate compilet generated files.  The settings files can be recreated at any time.  If they are wrong the only thing affected is the development environment.  The other files get recreated every time the code is run, plus they never get into production.  So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway.  Don't read more than what is stated otherwise you have a chance of being wrong and wasting time.  Someone was claiming the files are "important" which I never stated.  I didn't even respond to the mail since it was erroneous and irrelevant.


The real reason I responded is the force option eliminates the conflict but creates some questions.  The documentation says using it will make sure "unversioned obstructiong paths do not cause a failure".  Could that also be written as "unversioned obstructiong paths do not cause a conflict"?  Or is there some other kind of failure that I do not know about.

The problem this fixes displays as "Local unversioned, incoming add upon switch" which is the result of a switch.  The revert command fails to bring my working copy back to its unconflicted state.  Switching back also fails.

The question is can I bring back my working directory from a failed switch (I'm talking undo, not resolve) so I can use the force option or must I always use the force option to be able to switch branches?


Have a good weekend
JM
-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 5:17 PM
To: John Maher
Cc: Edwin Castro; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 1:34 PM, John Maher <Jo...@rotair.com> wrote:
> Again Les, you misunderstand.  I have no problems with the workspace.  It is exactly the same for everyone, everytime.  Please read carefully before you respond.  It has nothing to do with the build.  It is user settings, a config file, ini file, choose your terminology.  If you don't understand please ask for clarification instead of making incorrect assumptions.

The contents of the file are irrelevant.  The point is that it has to either be versioned so svn can delete it knowing that you can get it back, and then delete the containing directory that is really the issue, or you have to delete it yourself.  Pick one.  If it really is always the same, I don't see the problem with committing it.  If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably.
Personally, I don't like things that rely on any unversioned state getting into production releases.  That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 1:34 PM, John Maher <Jo...@rotair.com> wrote:
> Again Les, you misunderstand.  I have no problems with the workspace.  It is exactly the same for everyone, everytime.  Please read carefully before you respond.  It has nothing to do with the build.  It is user settings, a config file, ini file, choose your terminology.  If you don't understand please ask for clarification instead of making incorrect assumptions.

The contents of the file are irrelevant.  The point is that it has to
either be versioned so svn can delete it knowing that you can get it
back, and then delete the containing directory that is really the
issue, or you have to delete it yourself.  Pick one.  If it really is
always the same, I don't see the problem with committing it.  If it
isn't, and you need to reproduce it, you need to work out a way to do
that, or use the multiple-checkout approach to maintain dirty
workspaces, realizing that you can't reproduce them reliably.
Personally, I don't like things that rely on any unversioned state
getting into production releases.  That developer will leave or that
machine will crash and all the magic is gone - and if you can't do a
matching build on a clean machine from a clean checkout, you won't
ever know how much magic was involved.

-- 
   Les Mikesell
     lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

Again Les, you misunderstand.  I have no problems with the workspace.  It is exactly the same for everyone, everytime.  Please read carefully before you respond.  It has nothing to do with the build.  It is user settings, a config file, ini file, choose your terminology.  If you don't understand please ask for clarification instead of making incorrect assumptions.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 2:28 PM
To: John Maher
Cc: Edwin Castro; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 12:58 PM, John Maher <Jo...@rotair.com> wrote:
> You are correct that there will be issues with a fresh checkout.  But I can live with that.

Not caring if you can reproduce a workspace is a bold statement to make on a version control mail list.  Don't be surprised if everyone doesn't agree with that choice.

> The code will not be affected, just the way the code is tested.  Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it.

If this is preliminary testing, maybe that's OK.  If it is the whole story, I'd want it to be reproducible.

> Think config or settings file.

Think build automation where you'd want to be able to reproduce these on demand, not just rely on what happens to still live in the current filesystem.  It might take a one-time effort to find the files and decide how to handle them (renamed versioned copies, templates, moved local copies, etc.) but then aside from being able to switch among banches, you can reproduce a usable working copy.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 12:58 PM, John Maher <Jo...@rotair.com> wrote:
> You are correct that there will be issues with a fresh checkout.  But I can live with that.

Not caring if you can reproduce a workspace is a bold statement to
make on a version control mail list.  Don't be surprised if everyone
doesn't agree with that choice.

> The code will not be affected, just the way the code is tested.  Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it.

If this is preliminary testing, maybe that's OK.  If it is the whole
story, I'd want it to be reproducible.

> Think config or settings file.

Think build automation where you'd want to be able to reproduce these
on demand, not just rely on what happens to still live in the current
filesystem.  It might take a one-time effort to find the files and
decide how to handle them (renamed versioned copies, templates, moved
local copies, etc.) but then aside from being able to switch among
banches, you can reproduce a usable working copy.

-- 
   Les Mikesell
     lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

You are correct that there will be issues with a fresh checkout.  But I can live with that.  The code will not be affected, just the way the code is tested.  Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it.

Think config or settings file.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 1:53 PM
To: John Maher
Cc: Edwin Castro; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 12:43 PM, John Maher <Jo...@rotair.com> wrote:
>
> 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 an 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 them (as I incorrectly stated somewhere) but ignore them.

You are sort-of asking for trouble if you have any dependency on unversioned files being in a workspace at all, much less for them to continue to exist when switching among versions with/without the
containing directories.   I'd advise stepping back from the immediate
problem and thinking of processes that will always work with a fresh checkout so that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host.  It will simply your life even for manual operations if you can count on that.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 12:43 PM, John Maher <Jo...@rotair.com> wrote:
>
> 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 an 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 them (as I incorrectly stated somewhere) but ignore them.

You are sort-of asking for trouble if you have any dependency on
unversioned files being in a workspace at all, much less for them to
continue to exist when switching among versions with/without the
containing directories.   I'd advise stepping back from the immediate
problem and thinking of processes that will always work with a fresh
checkout so that in the future you can use build automation tools like
jenkins, relying only on the contents of the repository even when the
build happens on a new host.  It will simply your life even for manual
operations if you can count on that.

-- 
   Les Mikesell
     lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

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 an 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 them (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] 
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 <Jo...@rotair.com> wrote:
>> >
>> > @Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.
> Your problem is not so much that svn doesn't deleted the unversioned 
> 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 simplest of enhancements.
> Don't your build tools have commands to remove any spurious files 
> they've created or some equivalent of 'make clean' that you can run to 
> remove the clutter in a non-tedious way so that svn switch is free to 
> work correctly with the versioned content?
>

I typically run into this problem when a "build output" directory exists due 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 exists. 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 of the bin directory. The tree above is only an example. The branches I'm used to dealing with contain hundreds of such projects and building all of them 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 switch 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/projectA/ as unversioned (including the root/projectA/bin/ directory). Now that I'm done working with branch2 I try to svn switch back to branch1 and svn fails to add root/projectA/ because it already exists in the working copy unversioned.

We have a root build script that can run the clean target on all of our projects. Alternatively, I could run clean on individual projects prior to a switch but that requires that I know which projects do not exist on the target branch. I could also use the --force argument to svn switch but it carries 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 differences
     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 unversioned 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 you'll want to be very careful. It would probably be a good idea to follow up svn switch --force with svn status to see if anything becomes versioned that 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 typically 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 release 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 switch which can be very painful when you have as many projects as we do. If some of the ignored/unversioned files are user files that should not be versioned, then cleaning like this creates additional problems. We've worked around 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 server.

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 is created. Sometimes those files need to be kept in sync as merging occurs creating additional synching headaches. We found it much easier to avoid user files instead of managing their contents manually.

Most of our developers use a working copy per branch and avoid switch altogether but only because the guidelines they follow told them so.
Even then, rebuilding the entire tree took enough time that we wanted to avoid 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 projects we are currently working on is much simpler and faster than building the 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 everything so that developers do not have to remember the magic PowerShell incantation 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 daily 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 server.

--
Edwin G. Castro

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher <Jo...@rotair.com> wrote:
>> >
>> > @Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.
> Your problem is not so much that svn doesn't deleted the unversioned
> 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 simplest of enhancements.
> Don't your build tools have commands to remove any spurious files
> they've created or some equivalent of 'make clean' that you can run to
> remove the clutter in a non-tedious way so that svn switch is free to
> work correctly with the versioned content?
>

I typically run into this problem when a "build output" directory exists
due 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
exists. 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 of the bin directory. The tree above is only an example. The
branches I'm used to dealing with contain hundreds of such projects and
building all of them 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 switch 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/projectA/ as unversioned (including the root/projectA/bin/
directory). Now that I'm done working with branch2 I try to svn switch
back to branch1 and svn fails to add root/projectA/ because it already
exists in the working copy unversioned.

We have a root build script that can run the clean target on all of our
projects. Alternatively, I could run clean on individual projects prior
to a switch but that requires that I know which projects do not exist on
the target branch. I could also use the --force argument to svn switch
but it carries 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 differences
     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
unversioned 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 you'll want to be very careful. It would probably be a good
idea to follow up svn switch --force with svn status to see if anything
becomes versioned that 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
typically 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
release 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 switch which can be very painful when you have as many projects as
we do. If some of the ignored/unversioned files are user files that
should not be versioned, then cleaning like this creates additional
problems. We've worked around 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 server.

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 is created. Sometimes those files need to be kept in sync as
merging occurs creating additional synching headaches. We found it much
easier to avoid user files instead of managing their contents manually.

Most of our developers use a working copy per branch and avoid switch
altogether but only because the guidelines they follow told them so.
Even then, rebuilding the entire tree took enough time that we wanted to
avoid 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 projects we are currently working on is much simpler and faster
than building the 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 everything so that developers do not have to remember the
magic PowerShell incantation 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
daily 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 server.

--
Edwin G. Castro

RE: Switching

[Bob Archer <Bo...@amsi.com>]

> > -----Original Message-----
> > From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> > Sent: Thursday, August 22, 2013 12:21 PM
> > To: users@subversion.apache.org
> > Subject: Re: Switching
> >
> > How would you like Subversion to work in your case? From my
> > understanding it breaks down to something generated some files for
> > some reason in one of your branches and now you want to switch form
> > that branch to another which does not contain the base directory of
> > the generated files. What should subversion do with your generated
> > files it doesn't know anything about?
> >
> > I don't see how this problem can be solved by any tool.
> >
> 
> Part of his frustration is that the files in question are listed in the global-
> ignores.  So... maybe a feature request to have a 'svn switch' option to take
> global-ignores into consideration when deciding whether to keep or delete
> local files?
> 

I thought svn's policy was "do no harm"... so un-versioned files are never deleted by default.

BOb

RE: Switching

[Andrew Reedick <An...@cbeyond.net>]

> -----Original Message-----
> From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> Sent: Thursday, August 22, 2013 12:21 PM
> To: users@subversion.apache.org
> Subject: Re: Switching
> 
> How would you like Subversion to work in your case? From my
> understanding it breaks down to something generated some files for some
> reason in one of your branches and now you want to switch form that
> branch to another which does not contain the base directory of the
> generated files. What should subversion do with your generated files it
> doesn't know anything about?
> 
> I don't see how this problem can be solved by any tool.
> 

Part of his frustration is that the files in question are listed in the global-ignores.  So... maybe a feature request to have a 'svn switch' option to take global-ignores into consideration when deciding whether to keep or delete local files?

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 12:52 PM, John Maher <Jo...@rotair.com> wrote:
> I'll try to clarify, everyone has their own copy of the tool.  They also have their own copy of their settings.  The problem arises because the tool stores the settings files in the same folder as some code specific files.  This can not be changed.  So within a single directory we need to version some files and ignore others.
>
> Sure I could write a pre-processing program to do a multitude of things.  It wouldn't be that hard.  But then my plate has plenty of things that are not that hard.  What will I gain?

Things that don't mysteriously break?  Reproducible builds?   Are
those worth anything?

> A happy working copy with a single command as long as what I write always works perfectly.  Highly unlikely, so then I will make more problems for myself.  Plus I assigned myself the task of learning subversion.  Covering up a symptom does not treat the disease.

If you want to rely on the contents of dirty workspaces, just check
out different copies for each branch and let the cruft live there as
long as you need it.  You can still update/commit independently, etc.
 But you need to understand that the cruft is yours, not subversion's
and whatever you are doing isn't reproducible.

-- 
   Les Mikesell
     lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

I'll try to clarify, everyone has their own copy of the tool.  They also have their own copy of their settings.  The problem arises because the tool stores the settings files in the same folder as some code specific files.  This can not be changed.  So within a single directory we need to version some files and ignore others.

Sure I could write a pre-processing program to do a multitude of things.  It wouldn't be that hard.  But then my plate has plenty of things that are not that hard.  What will I gain?  A happy working copy with a single command as long as what I write always works perfectly.  Highly unlikely, so then I will make more problems for myself.  Plus I assigned myself the task of learning subversion.  Covering up a symptom does not treat the disease.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 1:30 PM
To: John Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 12:15 PM, John Maher <Jo...@rotair.com> wrote:
> "How about just 'delete the spurious unversioned files yourself'?"
>
> As I said in the previous reply, two of those files are user settings.  They would have to be constantly recreated by the developer.  That increases costs.  One of the reasons I wanted some form of source code control was to reduce costs.

So put them somewhere else or  version them - and if the tool can't deal with multiple users, work out a way to script a rename the
correct copy for the current user.   A clever developer should be able
to find an alternative to forcing subversion to keep a versioned directory in conflicting place or retyping a file to recreate it when needed...

Of course if it is too much trouble to clean up the files correctly, you can just delete the whole workspace and check out again to go between the branch/trunk versions.

> "Svn can't decide which of your files that it can't recreate for you should disappear."
>
> It could ignore files that it is instructed to ignore.  That would help.

How many people actually know which files subversion is ignoring?
Again, a clever developer could probably come up with his own way to delete files matching some patterns if he really wants that to happen.

--
  Les Mikesell
    lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 12:15 PM, John Maher <Jo...@rotair.com> wrote:
> "How about just 'delete the spurious unversioned files yourself'?"
>
> As I said in the previous reply, two of those files are user settings.  They would have to be constantly recreated by the developer.  That increases costs.  One of the reasons I wanted some form of source code control was to reduce costs.

So put them somewhere else or  version them - and if the tool can't
deal with multiple users, work out a way to script a rename the
correct copy for the current user.   A clever developer should be able
to find an alternative to forcing subversion to keep a versioned
directory in conflicting place or retyping a file to recreate it when
needed...

Of course if it is too much trouble to clean up the files correctly,
you can just delete the whole workspace and check out again to go
between the branch/trunk versions.

> "Svn can't decide which of your files that it can't recreate for you should disappear."
>
> It could ignore files that it is instructed to ignore.  That would help.

How many people actually know which files subversion is ignoring?
Again, a clever developer could probably come up with his own way to
delete files matching some patterns if he really wants that to happen.

-- 
  Les Mikesell
    lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

"How about just 'delete the spurious unversioned files yourself'?"

As I said in the previous reply, two of those files are user settings.  They would have to be constantly recreated by the developer.  That increases costs.  One of the reasons I wanted some form of source code control was to reduce costs.

"Svn can't decide which of your files that it can't recreate for you should disappear."

It could ignore files that it is instructed to ignore.  That would help.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 1:11 PM
To: John Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 11:40 AM, John Maher <Jo...@rotair.com> wrote:
> I don't think you even tried Thorsten,
>
> I can easily.  There are actually several options.

How about just 'delete the spurious unversioned files yourself'?   The
problem is the versioned directory containing them that is not supposed to exist after the switch.  And the only way svn can fix it for you is if you clean it up.  Svn can't decide which of your files
that it can't recreate for you should disappear.   Getting that wrong
would be much worse than presenting a conflict on the directory holding them.

-- 
    Les Mikesell
      lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 11:40 AM, John Maher <Jo...@rotair.com> wrote:
> I don't think you even tried Thorsten,
>
> I can easily.  There are actually several options.

How about just 'delete the spurious unversioned files yourself'?   The
problem is the versioned directory containing them that is not
supposed to exist after the switch.  And the only way svn can fix it
for you is if you clean it up.  Svn can't decide which of your files
that it can't recreate for you should disappear.   Getting that wrong
would be much worse than presenting a conflict on the directory
holding them.

-- 
    Les Mikesell
      lesmikesell@gmail.com

Re: Switching

[Dave Huang <kh...@azeotrope.org>]

On Aug 22, 2013, at 13:39, John Maher <Jo...@rotair.com> wrote:

> You digress.  Not a single one of the compiled libraries lives within the versioned directories.  Please read the question before replying incorrectly.  It has nothing to do with code.  It has nothing to do with the build.  Please ask for clarification if you do not understand.  You gave a good suggestion with the force option.  Then you wandered off to completely irrelevant ramblings.  Should quit while you're ahead.

It's getting obvious that you're not actually interested in the solutions the list has to give :(

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 02:18:59PM -0500, Les Mikesell wrote:
> On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling <st...@elego.de> wrote:
> > I hope that we will eventually extend tree conflict handling to the
> > point where it makes these kinds of situations trivial to resolve,
> > even for novice users. svn should interactively offer a set of
> > reasonable courses of action, such as removing the unversioned nodes,
> > or moving them to a special lost+found area, or something else that
> > allows incoming versioned nodes to be created in their place.
> 
> Yes, but it would be nice if one of the choices were to overwrite all
> unversioned directories and files with identical contents (but not
> files with different contents) - perhaps optionally listing any
> unversioned non-conflicting files that happen to be there.

Sure. If that's an option people consider useful we can add it to
a conflict menu, once it exists. I'm very open to suggestions because
we really don't know what users need in many such cases.

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
> If a previously versioned directory is left behind unversioned, that
> means there are unversioned (aka obstructing) nodes within the
> directory, such as files created during a build. Those files could
> not have been created by svn.

Sure, other tools besides subversion do some unintuitive things...

> I hope that we will eventually extend tree conflict handling to the
> point where it makes these kinds of situations trivial to resolve,
> even for novice users. svn should interactively offer a set of
> reasonable courses of action, such as removing the unversioned nodes,
> or moving them to a special lost+found area, or something else that
> allows incoming versioned nodes to be created in their place.

Yes, but it would be nice if one of the choices were to overwrite all
unversioned directories and files with identical contents (but not
files with different contents) - perhaps optionally listing any
unversioned non-conflicting files that happen to be there.

-- 
   Les Mikesell
     lesmikesell@gmail.com

RE: Switching

[John Maher <Jo...@rotair.com>]

Thanks Travis.

I thought this was a binary patch, not a source code patch.  Now I realize that since subversion gets compiled into a variety of executables a binary patch can not be done.  I do not wish to compile subversion. I have found that --force works and I only need it if switching to a branch that has any new libraries.  Switching away from that type of branch works fine.


-----Original Message-----
From: Travis Brown [mailto:travisb@travisbrown.ca] 
Sent: Monday, August 26, 2013 2:58 PM
To: John Maher
Cc: Subversion
Subject: Re: Switching

On Mon, Aug 26, 2013 at 01:31:49PM +0000, John Maher claimed:
>Hello
>
>Can you provide me with a link as to how to apply this patch?  When I search for applying a subversion patch all I get is stuff involving svn diff.  I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.
>

It's a patch you need to apply to the Subversion source code before building it. On a Unix-like system the following steps are what I do:

daredevil:~/temp $ tar -jxf subversion-1.8.1.tar.bz2 daredevil:~/temp $ cd subversion-1.8.1
daredevil:#emp/subversion-1.8.1 $ patch -p1 < ../local_unversioned_dir-incoming_add_dir.patch
patching file subversion/libsvn_wc/update_editor.c
Hunk #1 succeeded at 2249 (offset -1 lines).
daredevil:#emp/subversion-1.8.1 $

You would then go ahead and build Subversion as normal for whatever
platform(s) you are on. Unfortunately I cannot provide any guidance on how to accomplish this with a packaging system such as RPM or on Windows.

If you don't have existing infrastructure and procedures to install and update software installed from source then this patch may be a greater maintenance headache than it's worth.

--
Travis

>
>-----Original Message-----
>From: Travis Brown [mailto:travisb@travisbrown.ca]
>Sent: Saturday, August 24, 2013 5:58 PM
>To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; 
>dev@subversion.apache.org; John Maher
>Subject: Re: Switching
>
>On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>>> That's just overcomplicating the issue. This doesn't even need to 
>>> become a tree conflict.
>>
>>In my opinion it does need to be flagged as a conflict. Because we 
>>don't know what the contents of the incoming directory will be nor 
>>what the user may eventually want to do to resolve the problem.
>>Making the unversioned directory versioned is just one possible 
>>options among several.
>>
>>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
>
>I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about.
>
>John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it.
>
>Now I'll address Branko's points directly in a tedious fashion.
>
>
>>> You're assuming it is correct, in all cases, to silently make a 
>>> directory versioned because the incoming directory happens to have 
>>> the same name. It is not. It may be marginally correct in your case, 
>>> however, Subversion has no way of knowing that the unversioned 
>>> directory it sees is in any way related to whatever is on the 
>>> switched branch. It needs user input; it cannot magically become "smart enough".
>
>This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem.
>
>>> For example, consider a typical Java module which has "build.xml" 
>>> file and two directories, "src" and "test". You add such a module called "A"
>>> on the branch. Someone else creates a completely different and 
>>> unrelated module in their working copy, incidentally also calling it 
>>> "A". Then they switch to the branch. What happens?
>>>
>>> You're proposing that Subversion would say, "Oh, this unversioned 
>>> thing I have here is also called "A", I'm going to assume its the 
>>> same as the incoming directory, let's make it so." And in the next
>>> step: "Oh, I have an unversioned file called build.xml, I'll just 
>>> assume it's the same as the incoming and merge changes in...." boom, instant merge conflict.
>
>This goes further than this patch attempts. This patch only says "I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory." Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory.
>
>[As an aside a merge conflict is superior in every case to a tree 
>conflict. It would be useful if some other patch changed this case from 
>a tree conflict to a merge conflict where svn didn't try to merge 
>anything, but only gives you the Theirs, Mine, Edit (and equivalent) 
>options. But that's a separate discussion.]
>
>>> It actually gets worse, because following your proposal, Subversion 
>>> will happily recurse in the same way into src and test -- the final 
>>> result being an unholy mess that you're going to have a fine time 
>>> untangling, not to mention that you just messed up the poor user's 
>>> unversioned local changes.
>
>As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state.
>
>>> And of course, all of the above is not specific to switch -- but 
>>> also to update, when there are no branches involved.
>
>Of course the same issue where svn refuses to do the right thing exists during update. I'm pretty sure, but did not test, that my patch also covers this situation. What are the sensible user actions upon a local unversioned-incoming add tree conflict upon a _directory_ with no files within it?
>
>Delete it? Rename it to delete it later?
>
>What about a _directory_ with unversioned files within it? I suppose the user could delete the directory and all the files within it, or rename it and then move the files back later. The consensus of this list seems to be give up on switch as a uselessly broken feature. It's not like anybody would want to save all those build products or local configuration files to avoid multi-hour rebuilds when changing branches or anything.
>
>I'd be interested to hear of a single situation where _this_patch_, not some theoretical tree conflict resolving AI which bears no relation to this patch, does the wrong thing and the wrong thing is _worse_ than the existing functionality.
>
>--
>Travis
>
>[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml
>

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Mon, Aug 26, 2013 at 01:31:49PM +0000, John Maher claimed:
>Hello
>
>Can you provide me with a link as to how to apply this patch?  When I search for applying a subversion patch all I get is stuff involving svn diff.  I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.
>

It's a patch you need to apply to the Subversion source code before
building it. On a Unix-like system the following steps are what I do:

daredevil:~/temp $ tar -jxf subversion-1.8.1.tar.bz2
daredevil:~/temp $ cd subversion-1.8.1
daredevil:#emp/subversion-1.8.1 $ patch -p1 < ../local_unversioned_dir-incoming_add_dir.patch
patching file subversion/libsvn_wc/update_editor.c
Hunk #1 succeeded at 2249 (offset -1 lines).
daredevil:#emp/subversion-1.8.1 $

You would then go ahead and build Subversion as normal for whatever
platform(s) you are on. Unfortunately I cannot provide any guidance on
how to accomplish this with a packaging system such as RPM or on
Windows.

If you don't have existing infrastructure and procedures to install and
update software installed from source then this patch may be a greater
maintenance headache than it's worth.

-- 
Travis

>
>-----Original Message-----
>From: Travis Brown [mailto:travisb@travisbrown.ca] 
>Sent: Saturday, August 24, 2013 5:58 PM
>To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; dev@subversion.apache.org; John Maher
>Subject: Re: Switching
>
>On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>>> That's just overcomplicating the issue. This doesn't even need to 
>>> become a tree conflict.
>>
>>In my opinion it does need to be flagged as a conflict. Because we 
>>don't know what the contents of the incoming directory will be nor what 
>>the user may eventually want to do to resolve the problem.
>>Making the unversioned directory versioned is just one possible options 
>>among several.
>>
>>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
>
>I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about.
>
>John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it.
>
>Now I'll address Branko's points directly in a tedious fashion.
>
>
>>> You're assuming it is correct, in all cases, to silently make a 
>>> directory versioned because the incoming directory happens to have 
>>> the same name. It is not. It may be marginally correct in your case, 
>>> however, Subversion has no way of knowing that the unversioned 
>>> directory it sees is in any way related to whatever is on the 
>>> switched branch. It needs user input; it cannot magically become "smart enough".
>
>This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem.
>
>>> For example, consider a typical Java module which has "build.xml" 
>>> file and two directories, "src" and "test". You add such a module called "A"
>>> on the branch. Someone else creates a completely different and 
>>> unrelated module in their working copy, incidentally also calling it 
>>> "A". Then they switch to the branch. What happens?
>>>
>>> You're proposing that Subversion would say, "Oh, this unversioned 
>>> thing I have here is also called "A", I'm going to assume its the 
>>> same as the incoming directory, let's make it so." And in the next 
>>> step: "Oh, I have an unversioned file called build.xml, I'll just 
>>> assume it's the same as the incoming and merge changes in...." boom, instant merge conflict.
>
>This goes further than this patch attempts. This patch only says "I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory." Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory.
>
>[As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.]
>
>>> It actually gets worse, because following your proposal, Subversion 
>>> will happily recurse in the same way into src and test -- the final 
>>> result being an unholy mess that you're going to have a fine time 
>>> untangling, not to mention that you just messed up the poor user's 
>>> unversioned local changes.
>
>As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state.
>
>>> And of course, all of the above is not specific to switch -- but also 
>>> to update, when there are no branches involved.
>
>Of course the same issue where svn refuses to do the right thing exists during update. I'm pretty sure, but did not test, that my patch also covers this situation. What are the sensible user actions upon a local unversioned-incoming add tree conflict upon a _directory_ with no files within it?
>
>Delete it? Rename it to delete it later?
>
>What about a _directory_ with unversioned files within it? I suppose the user could delete the directory and all the files within it, or rename it and then move the files back later. The consensus of this list seems to be give up on switch as a uselessly broken feature. It's not like anybody would want to save all those build products or local configuration files to avoid multi-hour rebuilds when changing branches or anything.
>
>I'd be interested to hear of a single situation where _this_patch_, not some theoretical tree conflict resolving AI which bears no relation to this patch, does the wrong thing and the wrong thing is _worse_ than the existing functionality.
>
>--
>Travis
>
>[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml
>

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sun, Aug 25, 2013 at 03:44:05PM -0700, Travis Brown wrote:
> I took a brief look at the resolution code and found it to be a twisty
> maze of callbacks and workqueues. There didn't appear to be any existing
> infrastructure or obvious way to resolve the tree conflict on the
> directory and then continue with whatever operation caused the conflict
> in the first place.

I agree the layering is somewhat complex. 'svn resolve' now contains
several operations similar to update and merge, and which had to be
implemented from scratch where the existing update/merge code couldn't
be used without modification.

The callbacks are either conflict resolution callbacks that are needed
to support different client implementations at the API level, or they're
the editor callbacks which give the resolution code a structure similar
to the update and merge code. Technically, the editor API wouldn't be
needed within 'svn resolve', as it is intended to work primarily offline.
However, it may need to contact a server in the future. Also, we decided
to use the new resolver as a test bed for the new EditorV2 API, which
hasn't seen much use otherwise (expect in JavaHL and experimental branches).

You'd probably have to add a new operation within the wc_db code first
and then work your way up.

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sun, Aug 25, 2013 at 03:44:05PM -0700, Travis Brown wrote:
> I took a brief look at the resolution code and found it to be a twisty
> maze of callbacks and workqueues. There didn't appear to be any existing
> infrastructure or obvious way to resolve the tree conflict on the
> directory and then continue with whatever operation caused the conflict
> in the first place.

I agree the layering is somewhat complex. 'svn resolve' now contains
several operations similar to update and merge, and which had to be
implemented from scratch where the existing update/merge code couldn't
be used without modification.

The callbacks are either conflict resolution callbacks that are needed
to support different client implementations at the API level, or they're
the editor callbacks which give the resolution code a structure similar
to the update and merge code. Technically, the editor API wouldn't be
needed within 'svn resolve', as it is intended to work primarily offline.
However, it may need to contact a server in the future. Also, we decided
to use the new resolver as a test bed for the new EditorV2 API, which
hasn't seen much use otherwise (expect in JavaHL and experimental branches).

You'd probably have to add a new operation within the wc_db code first
and then work your way up.

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sun, Aug 25, 2013 at 11:46:11AM +0200, Stefan Sperling claimed:
>Looking at just one use case is not going to help us in the long term.
>And I don't think we should hard-code conflict resolution behaviour in
>the update/switch/merge logic.
>
>During 1.8 development, I did experiment with hard-coded conflict
>resolution choices on several occasions (see, for example,
>http://svn.apache.org/r1161219). Those changes got shot down during
>peer review, because there were cases where the hard-coded behaviour
>was problematic. More importantly, intertwining conflict resolution
>with the update/merge logic tends to make the code overly complicated
>and fragile once we look past trivial conflict cases.
>
>So our current approach is to always flag conflicts during update and
>merge, and then let 'svn resolve' deal with these conflicts in a
>separate step. I would consider your patch if it made 'svn resolve'
>deal with the tree conflict raised on the obstructing directory,
>rather than changing how 'svn switch' behaves now.
>
>We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
>also started to improve the interactive menu for tree conflicts involving
>local moves. I'd like to see further improvements there, even if it's
>harder than patching up a few use cases. I think we'll get a more
>flexible and reliable system in the long term this way.

It's nice to finally see a concrete, technical objection.

I took a brief look at the resolution code and found it to be a twisty
maze of callbacks and workqueues. There didn't appear to be any existing
infrastructure or obvious way to resolve the tree conflict on the
directory and then continue with whatever operation caused the conflict
in the first place. This isn't my itch so I'm uninterested in spending
any more time than I have already investigating it. IMHO any solution to
this problem which requires any further user input, whether a manual
conflict resolution or running a second command, is a waste of time.
What I saw in my brief look indicates that it'll be a significant effort
to accomplish this level of polish with the existing code structure.

Since my patch has legitimate objections and I'm not willing to
implement the supported alternative I'll let this drop now.

-- 
Travis

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sun, Aug 25, 2013 at 11:46:11AM +0200, Stefan Sperling claimed:
>Looking at just one use case is not going to help us in the long term.
>And I don't think we should hard-code conflict resolution behaviour in
>the update/switch/merge logic.
>
>During 1.8 development, I did experiment with hard-coded conflict
>resolution choices on several occasions (see, for example,
>http://svn.apache.org/r1161219). Those changes got shot down during
>peer review, because there were cases where the hard-coded behaviour
>was problematic. More importantly, intertwining conflict resolution
>with the update/merge logic tends to make the code overly complicated
>and fragile once we look past trivial conflict cases.
>
>So our current approach is to always flag conflicts during update and
>merge, and then let 'svn resolve' deal with these conflicts in a
>separate step. I would consider your patch if it made 'svn resolve'
>deal with the tree conflict raised on the obstructing directory,
>rather than changing how 'svn switch' behaves now.
>
>We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
>also started to improve the interactive menu for tree conflicts involving
>local moves. I'd like to see further improvements there, even if it's
>harder than patching up a few use cases. I think we'll get a more
>flexible and reliable system in the long term this way.

It's nice to finally see a concrete, technical objection.

I took a brief look at the resolution code and found it to be a twisty
maze of callbacks and workqueues. There didn't appear to be any existing
infrastructure or obvious way to resolve the tree conflict on the
directory and then continue with whatever operation caused the conflict
in the first place. This isn't my itch so I'm uninterested in spending
any more time than I have already investigating it. IMHO any solution to
this problem which requires any further user input, whether a manual
conflict resolution or running a second command, is a waste of time.
What I saw in my brief look indicates that it'll be a significant effort
to accomplish this level of polish with the existing code structure.

Since my patch has legitimate objections and I'm not willing to
implement the supported alternative I'll let this drop now.

-- 
Travis

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 02:57:50PM -0700, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
> >On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> >> That's just overcomplicating the issue. This doesn't even need to
> >> become a tree conflict.
> >
> >In my opinion it does need to be flagged as a conflict. Because we
> >don't know what the contents of the incoming directory will be nor
> >what the user may eventually want to do to resolve the problem.
> >Making the unversioned directory versioned is just one possible
> >options among several.
> >
> >See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
> 
> I read that and I still wrote and posted the patch because the arguments
> there bear no relation to what _this_ patch does. That post does a fine
> job describing a few challenges for what a more complete system would
> do. This patch just makes the ratchet not cut the user's knuckles when
> they reverse direction, it isn't the fully automated manufacturing plant
> most of this thread seem to be talking about.

Looking at just one use case is not going to help us in the long term.
And I don't think we should hard-code conflict resolution behaviour in
the update/switch/merge logic.

During 1.8 development, I did experiment with hard-coded conflict
resolution choices on several occasions (see, for example,
http://svn.apache.org/r1161219). Those changes got shot down during
peer review, because there were cases where the hard-coded behaviour
was problematic. More importantly, intertwining conflict resolution
with the update/merge logic tends to make the code overly complicated
and fragile once we look past trivial conflict cases.

So our current approach is to always flag conflicts during update and
merge, and then let 'svn resolve' deal with these conflicts in a
separate step. I would consider your patch if it made 'svn resolve'
deal with the tree conflict raised on the obstructing directory,
rather than changing how 'svn switch' behaves now.

We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
also started to improve the interactive menu for tree conflicts involving
local moves. I'd like to see further improvements there, even if it's
harder than patching up a few use cases. I think we'll get a more
flexible and reliable system in the long term this way.

Re: Switching

[Branko Čibej <br...@wandisco.com>]

On 26.08.2013 15:31, John Maher wrote:
> Hello
>
> Can you provide me with a link as to how to apply this patch?  When I search for applying a subversion patch all I get is stuff involving svn diff.  I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.

Try "svn help patch".

But here's a fair warning: According to us devs, the patch is not the
correct solution. If you apply it and it breaks some other use case,
please don't complain about it on this list.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

RE: Switching

[John Maher <Jo...@rotair.com>]

Hello

Can you provide me with a link as to how to apply this patch?  When I search for applying a subversion patch all I get is stuff involving svn diff.  I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.


-----Original Message-----
From: Travis Brown [mailto:travisb@travisbrown.ca] 
Sent: Saturday, August 24, 2013 5:58 PM
To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; dev@subversion.apache.org; John Maher
Subject: Re: Switching

On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to 
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we 
>don't know what the contents of the incoming directory will be nor what 
>the user may eventually want to do to resolve the problem.
>Making the unversioned directory versioned is just one possible options 
>among several.
>
>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about.

John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it.

Now I'll address Branko's points directly in a tedious fashion.


>> You're assuming it is correct, in all cases, to silently make a 
>> directory versioned because the incoming directory happens to have 
>> the same name. It is not. It may be marginally correct in your case, 
>> however, Subversion has no way of knowing that the unversioned 
>> directory it sees is in any way related to whatever is on the 
>> switched branch. It needs user input; it cannot magically become "smart enough".

This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem.

>> For example, consider a typical Java module which has "build.xml" 
>> file and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and 
>> unrelated module in their working copy, incidentally also calling it 
>> "A". Then they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned 
>> thing I have here is also called "A", I'm going to assume its the 
>> same as the incoming directory, let's make it so." And in the next 
>> step: "Oh, I have an unversioned file called build.xml, I'll just 
>> assume it's the same as the incoming and merge changes in...." boom, instant merge conflict.

This goes further than this patch attempts. This patch only says "I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory." Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory.

[As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.]

>> It actually gets worse, because following your proposal, Subversion 
>> will happily recurse in the same way into src and test -- the final 
>> result being an unholy mess that you're going to have a fine time 
>> untangling, not to mention that you just messed up the poor user's 
>> unversioned local changes.

As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state.

>> And of course, all of the above is not specific to switch -- but also 
>> to update, when there are no branches involved.

Of course the same issue where svn refuses to do the right thing exists during update. I'm pretty sure, but did not test, that my patch also covers this situation. What are the sensible user actions upon a local unversioned-incoming add tree conflict upon a _directory_ with no files within it?

Delete it? Rename it to delete it later?

What about a _directory_ with unversioned files within it? I suppose the user could delete the directory and all the files within it, or rename it and then move the files back later. The consensus of this list seems to be give up on switch as a uselessly broken feature. It's not like anybody would want to save all those build products or local configuration files to avoid multi-hour rebuilds when changing branches or anything.

I'd be interested to hear of a single situation where _this_patch_, not some theoretical tree conflict resolving AI which bears no relation to this patch, does the wrong thing and the wrong thing is _worse_ than the existing functionality.

--
Travis

[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 02:57:50PM -0700, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
> >On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> >> That's just overcomplicating the issue. This doesn't even need to
> >> become a tree conflict.
> >
> >In my opinion it does need to be flagged as a conflict. Because we
> >don't know what the contents of the incoming directory will be nor
> >what the user may eventually want to do to resolve the problem.
> >Making the unversioned directory versioned is just one possible
> >options among several.
> >
> >See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
> 
> I read that and I still wrote and posted the patch because the arguments
> there bear no relation to what _this_ patch does. That post does a fine
> job describing a few challenges for what a more complete system would
> do. This patch just makes the ratchet not cut the user's knuckles when
> they reverse direction, it isn't the fully automated manufacturing plant
> most of this thread seem to be talking about.

Looking at just one use case is not going to help us in the long term.
And I don't think we should hard-code conflict resolution behaviour in
the update/switch/merge logic.

During 1.8 development, I did experiment with hard-coded conflict
resolution choices on several occasions (see, for example,
http://svn.apache.org/r1161219). Those changes got shot down during
peer review, because there were cases where the hard-coded behaviour
was problematic. More importantly, intertwining conflict resolution
with the update/merge logic tends to make the code overly complicated
and fragile once we look past trivial conflict cases.

So our current approach is to always flag conflicts during update and
merge, and then let 'svn resolve' deal with these conflicts in a
separate step. I would consider your patch if it made 'svn resolve'
deal with the tree conflict raised on the obstructing directory,
rather than changing how 'svn switch' behaves now.

We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
also started to improve the interactive menu for tree conflicts involving
local moves. I'd like to see further improvements there, even if it's
harder than patching up a few use cases. I think we'll get a more
flexible and reliable system in the long term this way.

Re: Switching

[Branko Čibej <br...@wandisco.com>]

[not cross-posting to users@ as this is a dev@ topic]

On 24.08.2013 23:57, Travis Brown wrote:
> I'd be interested to hear of a single situation where _this_patch_,
> not some theoretical tree conflict resolving AI which bears no
> relation to this patch, does the wrong thing and the wrong thing is
> _worse_ than the existing functionality. 

Since your patch does not affect the behaviour with files, you'll get
tree conflicts on any identically-named files, not merge conflicts (see
my build.xml example). I frankly fail to see how that's better than
having one tree conflict on the directory.

Even assuming the ideal situation where the intersection of the contents
of the (unversioned) local tree and the incoming tree is empty (i.e.,
the trees are completely different except for being rooted on a
directory with the same name), so you don't get any tree conflicts on
files, the result will be a union of those contents.

Now for the particular use case that started this whole discussion,
where the unversioned contents consist entirely of generated files,
that's not a problem (barring strange effects on build tools). But for
every other case it is, so you can hardly claim that your patch would
have no adverse consequences, especially as the assumption is that
Subversion would merge the trees silently, without even warning the
user. You could end up with two distinct and perhaps conflicting modules
merged into one, with the extra bonus that your build might not even
fail. Seems like a good way for introducing bugs into the code base. :)

(Not to mention that from the point of view of CM processes and
repeatable builds, this is a nightmare).

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

RE: Switching

[John Maher <Jo...@rotair.com>]

Hello

Can you provide me with a link as to how to apply this patch?  When I search for applying a subversion patch all I get is stuff involving svn diff.  I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.


-----Original Message-----
From: Travis Brown [mailto:travisb@travisbrown.ca] 
Sent: Saturday, August 24, 2013 5:58 PM
To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; dev@subversion.apache.org; John Maher
Subject: Re: Switching

On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to 
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we 
>don't know what the contents of the incoming directory will be nor what 
>the user may eventually want to do to resolve the problem.
>Making the unversioned directory versioned is just one possible options 
>among several.
>
>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about.

John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it.

Now I'll address Branko's points directly in a tedious fashion.


>> You're assuming it is correct, in all cases, to silently make a 
>> directory versioned because the incoming directory happens to have 
>> the same name. It is not. It may be marginally correct in your case, 
>> however, Subversion has no way of knowing that the unversioned 
>> directory it sees is in any way related to whatever is on the 
>> switched branch. It needs user input; it cannot magically become "smart enough".

This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem.

>> For example, consider a typical Java module which has "build.xml" 
>> file and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and 
>> unrelated module in their working copy, incidentally also calling it 
>> "A". Then they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned 
>> thing I have here is also called "A", I'm going to assume its the 
>> same as the incoming directory, let's make it so." And in the next 
>> step: "Oh, I have an unversioned file called build.xml, I'll just 
>> assume it's the same as the incoming and merge changes in...." boom, instant merge conflict.

This goes further than this patch attempts. This patch only says "I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory." Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory.

[As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.]

>> It actually gets worse, because following your proposal, Subversion 
>> will happily recurse in the same way into src and test -- the final 
>> result being an unholy mess that you're going to have a fine time 
>> untangling, not to mention that you just messed up the poor user's 
>> unversioned local changes.

As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state.

>> And of course, all of the above is not specific to switch -- but also 
>> to update, when there are no branches involved.

Of course the same issue where svn refuses to do the right thing exists during update. I'm pretty sure, but did not test, that my patch also covers this situation. What are the sensible user actions upon a local unversioned-incoming add tree conflict upon a _directory_ with no files within it?

Delete it? Rename it to delete it later?

What about a _directory_ with unversioned files within it? I suppose the user could delete the directory and all the files within it, or rename it and then move the files back later. The consensus of this list seems to be give up on switch as a uselessly broken feature. It's not like anybody would want to save all those build products or local configuration files to avoid multi-hour rebuilds when changing branches or anything.

I'd be interested to hear of a single situation where _this_patch_, not some theoretical tree conflict resolving AI which bears no relation to this patch, does the wrong thing and the wrong thing is _worse_ than the existing functionality.

--
Travis

[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we
>don't know what the contents of the incoming directory will be nor
>what the user may eventually want to do to resolve the problem.
>Making the unversioned directory versioned is just one possible
>options among several.
>
>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

I read that and I still wrote and posted the patch because the arguments
there bear no relation to what _this_ patch does. That post does a fine
job describing a few challenges for what a more complete system would
do. This patch just makes the ratchet not cut the user's knuckles when
they reverse direction, it isn't the fully automated manufacturing plant
most of this thread seem to be talking about.

John, before I go onto to exhaustively say my final piece on this matter,
you have my patch[0] which I believe makes your use case work. If you
have the resources to run an otherwise standard SVN binary with this
patch applied I would consider doing it.

Now I'll address Branko's points directly in a tedious fashion.


>> You're assuming it is correct, in all cases, to silently make a
>> directory versioned because the incoming directory happens to have the
>> same name. It is not. It may be marginally correct in your case,
>> however, Subversion has no way of knowing that the unversioned directory
>> it sees is in any way related to whatever is on the switched branch. It
>> needs user input; it cannot magically become "smart enough".

This thinking is much higher level and trying to do much more than this
patch. This patch doesn't attempt to deal with trying to merge the
existing unversioned file hierarchy and the incoming version object
hierarchy. It merely avoids unnecessary tree conflicts on directories
in _one_ specific case. The general problem is hard, but this is not the
general problem.

>> For example, consider a typical Java module which has "build.xml" file
>> and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and unrelated
>> module in their working copy, incidentally also calling it "A". Then
>> they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned thing
>> I have here is also called "A", I'm going to assume its the same as the
>> incoming directory, let's make it so." And in the next step: "Oh, I have
>> an unversioned file called build.xml, I'll just assume it's the same as
>> the incoming and merge changes in...." boom, instant merge conflict.

This goes further than this patch attempts. This patch only says "I see
you have an existing directory called A. I won't make you move/delete
it, instead I'll just continue on filling in this hierarchy as if I
created this directory." Significantly, this patch doesn't change
anything about how _files_ within this hierarchy are dealt with. If you
have an unversioned _file_ within the directory with the same name as in
incoming versioned object then you still get a tree conflict as you
would in a similar situation without an incoming directory.

[As an aside a merge conflict is superior in every case to a tree
conflict. It would be useful if some other patch changed this case from
a tree conflict to a merge conflict where svn didn't try to merge
anything, but only gives you the Theirs, Mine, Edit (and equivalent)
options. But that's a separate discussion.]

>> It actually gets worse, because following your proposal, Subversion will
>> happily recurse in the same way into src and test -- the final result
>> being an unholy mess that you're going to have a fine time untangling,
>> not to mention that you just messed up the poor user's unversioned local
>> changes.

As noted above this patch doesn't modify _anything_ local in any way
which is not obviously reversible. The existing directory has no
permissions or properties changed. No existing files are modified at
all. The directory now contains files it didn't originally, but svn will
tell you which files were originally there since they are either
unversioned or in the conflict state.

>> And of course, all of the above is not specific to switch -- but also to
>> update, when there are no branches involved. 

Of course the same issue where svn refuses to do the right thing exists
during update. I'm pretty sure, but did not test, that my patch also
covers this situation. What are the sensible user actions upon a local
unversioned-incoming add tree conflict upon a _directory_ with no files
within it?

Delete it? Rename it to delete it later?

What about a _directory_ with unversioned files within it? I suppose the
user could delete the directory and all the files within it, or rename
it and then move the files back later. The consensus of this list seems
to be give up on switch as a uselessly broken feature. It's not like
anybody would want to save all those build products or local
configuration files to avoid multi-hour rebuilds when changing branches
or anything.

I'd be interested to hear of a single situation where _this_patch_, not
some theoretical tree conflict resolving AI which bears no relation to
this patch, does the wrong thing and the wrong thing is _worse_ than the
existing functionality.

-- 
Travis

[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we
>don't know what the contents of the incoming directory will be nor
>what the user may eventually want to do to resolve the problem.
>Making the unversioned directory versioned is just one possible
>options among several.
>
>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

I read that and I still wrote and posted the patch because the arguments
there bear no relation to what _this_ patch does. That post does a fine
job describing a few challenges for what a more complete system would
do. This patch just makes the ratchet not cut the user's knuckles when
they reverse direction, it isn't the fully automated manufacturing plant
most of this thread seem to be talking about.

John, before I go onto to exhaustively say my final piece on this matter,
you have my patch[0] which I believe makes your use case work. If you
have the resources to run an otherwise standard SVN binary with this
patch applied I would consider doing it.

Now I'll address Branko's points directly in a tedious fashion.


>> You're assuming it is correct, in all cases, to silently make a
>> directory versioned because the incoming directory happens to have the
>> same name. It is not. It may be marginally correct in your case,
>> however, Subversion has no way of knowing that the unversioned directory
>> it sees is in any way related to whatever is on the switched branch. It
>> needs user input; it cannot magically become "smart enough".

This thinking is much higher level and trying to do much more than this
patch. This patch doesn't attempt to deal with trying to merge the
existing unversioned file hierarchy and the incoming version object
hierarchy. It merely avoids unnecessary tree conflicts on directories
in _one_ specific case. The general problem is hard, but this is not the
general problem.

>> For example, consider a typical Java module which has "build.xml" file
>> and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and unrelated
>> module in their working copy, incidentally also calling it "A". Then
>> they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned thing
>> I have here is also called "A", I'm going to assume its the same as the
>> incoming directory, let's make it so." And in the next step: "Oh, I have
>> an unversioned file called build.xml, I'll just assume it's the same as
>> the incoming and merge changes in...." boom, instant merge conflict.

This goes further than this patch attempts. This patch only says "I see
you have an existing directory called A. I won't make you move/delete
it, instead I'll just continue on filling in this hierarchy as if I
created this directory." Significantly, this patch doesn't change
anything about how _files_ within this hierarchy are dealt with. If you
have an unversioned _file_ within the directory with the same name as in
incoming versioned object then you still get a tree conflict as you
would in a similar situation without an incoming directory.

[As an aside a merge conflict is superior in every case to a tree
conflict. It would be useful if some other patch changed this case from
a tree conflict to a merge conflict where svn didn't try to merge
anything, but only gives you the Theirs, Mine, Edit (and equivalent)
options. But that's a separate discussion.]

>> It actually gets worse, because following your proposal, Subversion will
>> happily recurse in the same way into src and test -- the final result
>> being an unholy mess that you're going to have a fine time untangling,
>> not to mention that you just messed up the poor user's unversioned local
>> changes.

As noted above this patch doesn't modify _anything_ local in any way
which is not obviously reversible. The existing directory has no
permissions or properties changed. No existing files are modified at
all. The directory now contains files it didn't originally, but svn will
tell you which files were originally there since they are either
unversioned or in the conflict state.

>> And of course, all of the above is not specific to switch -- but also to
>> update, when there are no branches involved. 

Of course the same issue where svn refuses to do the right thing exists
during update. I'm pretty sure, but did not test, that my patch also
covers this situation. What are the sensible user actions upon a local
unversioned-incoming add tree conflict upon a _directory_ with no files
within it?

Delete it? Rename it to delete it later?

What about a _directory_ with unversioned files within it? I suppose the
user could delete the directory and all the files within it, or rename
it and then move the files back later. The consensus of this list seems
to be give up on switch as a uselessly broken feature. It's not like
anybody would want to save all those build products or local
configuration files to avoid multi-hour rebuilds when changing branches
or anything.

I'd be interested to hear of a single situation where _this_patch_, not
some theoretical tree conflict resolving AI which bears no relation to
this patch, does the wrong thing and the wrong thing is _worse_ than the
existing functionality.

-- 
Travis

[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict.

In my opinion it does need to be flagged as a conflict. Because we
don't know what the contents of the incoming directory will be nor
what the user may eventually want to do to resolve the problem.
Making the unversioned directory versioned is just one possible
options among several.

See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict.

In my opinion it does need to be flagged as a conflict. Because we
don't know what the contents of the incoming directory will be nor
what the user may eventually want to do to resolve the problem.
Making the unversioned directory versioned is just one possible
options among several.

See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

Re: Switching

[Branko Čibej <br...@wandisco.com>]

On 24.08.2013 21:26, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>>> Don't forget that it was subversion, not the user, that created the
>>> directory and abandoned it in the first place.
>> If a previously versioned directory is left behind unversioned, that
>> means there are unversioned (aka obstructing) nodes within the
>> directory, such as files created during a build. Those files could
>> not have been created by svn.
>>
>> I hope that we will eventually extend tree conflict handling to the
>> point where it makes these kinds of situations trivial to resolve,
>> even for novice users. svn should interactively offer a set of
>> reasonable courses of action, such as removing the unversioned nodes,
>> or moving them to a special lost+found area, or something else that
>> allows incoming versioned nodes to be created in their place.
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict. There seems to be confusion about what is
> actually needed to solve the OP's original problem and to make svn
> switch symmetric. I've attached a simple patch which solves the issue in
> the method that I proposed.

I already explained at length why this solution is absolutely the wrong
approach. It solves a small subset of cases at the cost of causing
serious grief to users in the majority of cases. Let's please just stop
discussing this approach because it is not viable.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Switching

[Branko Čibej <br...@wandisco.com>]

On 24.08.2013 21:26, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>>> Don't forget that it was subversion, not the user, that created the
>>> directory and abandoned it in the first place.
>> If a previously versioned directory is left behind unversioned, that
>> means there are unversioned (aka obstructing) nodes within the
>> directory, such as files created during a build. Those files could
>> not have been created by svn.
>>
>> I hope that we will eventually extend tree conflict handling to the
>> point where it makes these kinds of situations trivial to resolve,
>> even for novice users. svn should interactively offer a set of
>> reasonable courses of action, such as removing the unversioned nodes,
>> or moving them to a special lost+found area, or something else that
>> allows incoming versioned nodes to be created in their place.
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict. There seems to be confusion about what is
> actually needed to solve the OP's original problem and to make svn
> switch symmetric. I've attached a simple patch which solves the issue in
> the method that I proposed.

I already explained at length why this solution is absolutely the wrong
approach. It solves a small subset of cases at the cost of causing
serious grief to users in the majority of cases. Let's please just stop
discussing this approach because it is not viable.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
>If a previously versioned directory is left behind unversioned, that
>means there are unversioned (aka obstructing) nodes within the
>directory, such as files created during a build. Those files could
>not have been created by svn.
>
>I hope that we will eventually extend tree conflict handling to the
>point where it makes these kinds of situations trivial to resolve,
>even for novice users. svn should interactively offer a set of
>reasonable courses of action, such as removing the unversioned nodes,
>or moving them to a special lost+found area, or something else that
>allows incoming versioned nodes to be created in their place.

That's just overcomplicating the issue. This doesn't even need to
become a tree conflict. There seems to be confusion about what is
actually needed to solve the OP's original problem and to make svn
switch symmetric. I've attached a simple patch which solves the issue in
the method that I proposed. I've tested it manually and it's fine, but
I haven't run it through the test suite and haven't covered the
directory permission difference case. I'm not sure it is even desirable
to check the directory permissions.

-- 
Travis

Re: Switching

[Travis Brown <tr...@travisbrown.ca>]

On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
>If a previously versioned directory is left behind unversioned, that
>means there are unversioned (aka obstructing) nodes within the
>directory, such as files created during a build. Those files could
>not have been created by svn.
>
>I hope that we will eventually extend tree conflict handling to the
>point where it makes these kinds of situations trivial to resolve,
>even for novice users. svn should interactively offer a set of
>reasonable courses of action, such as removing the unversioned nodes,
>or moving them to a special lost+found area, or something else that
>allows incoming versioned nodes to be created in their place.

That's just overcomplicating the issue. This doesn't even need to
become a tree conflict. There seems to be confusion about what is
actually needed to solve the OP's original problem and to make svn
switch symmetric. I've attached a simple patch which solves the issue in
the method that I proposed. I've tested it manually and it's fine, but
I haven't run it through the test suite and haven't covered the
directory permission difference case. I'm not sure it is even desirable
to check the directory permissions.

-- 
Travis

Re: Switching

[Stefan Sperling <st...@elego.de>]

On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
> Don't forget that it was subversion, not the user, that created the
> directory and abandoned it in the first place.

If a previously versioned directory is left behind unversioned, that
means there are unversioned (aka obstructing) nodes within the
directory, such as files created during a build. Those files could
not have been created by svn.

I hope that we will eventually extend tree conflict handling to the
point where it makes these kinds of situations trivial to resolve,
even for novice users. svn should interactively offer a set of
reasonable courses of action, such as removing the unversioned nodes,
or moving them to a special lost+found area, or something else that
allows incoming versioned nodes to be created in their place.

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Sat, Aug 24, 2013 at 2:48 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>
>>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>>
>>>>> I can't, off the top of my head, think of a scenario where it would be
>>>>> harmful to replace an unversioned directory with a versioned instance,
>>>>> leaving any unversioned local files that happen to be there alone.
>>>> Leaving unversioned local files alone in a directory is not the problem.
>>> I think it is the problem we've been discussing.  Leaving them means
>>> you have to keep the containing directory, which becomes unversioned
>>> as you switch away from the branch having it,
>> Correct.
>>
>>> and then a conflict when
>>> you switch back.
>> *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.
>
> You're assuming it is correct, in all cases, to silently make a
> directory versioned because the incoming directory happens to have the
> same name. It is not. It may be marginally correct in your case,
> however, Subversion has no way of knowing that the unversioned directory
> it sees is in any way related to whatever is on the switched branch. It
> needs user input; it cannot magically become "smart enough".
>
> For example, consider a typical Java module which has "build.xml" file
> and two directories, "src" and "test". You add such a module called "A"
> on the branch. Someone else creates a completely different and unrelated
> module in their working copy, incidentally also calling it "A". Then
> they switch to the branch. What happens?
>
> You're proposing that Subversion would say, "Oh, this unversioned thing
> I have here is also called "A", I'm going to assume its the same as the
> incoming directory, let's make it so." And in the next step: "Oh, I have
> an unversioned file called build.xml, I'll just assume it's the same as
> the incoming and merge changes in...." boom, instant merge conflict.
>
> It actually gets worse, because following your proposal, Subversion will
> happily recurse in the same way into src and test -- the final result
> being an unholy mess that you're going to have a fine time untangling,
> not to mention that you just messed up the poor user's unversioned local
> changes.
>
> And of course, all of the above is not specific to switch -- but also to
> update, when there are no branches involved.
>
> So, yeah, it ain't gonna happen. You /do/ have the option to use
> --force, but there's a reason why that isn't the default.
>
> -- Brane
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane@wandisco.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Sat, Aug 24, 2013 at 6:51 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>
>>> *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.
>>
>> You're assuming it is correct, in all cases, to silently make a
>> directory versioned because the incoming directory happens to have the
>> same name.

I'm not sure anyone proposed silently assuming anything.  I'd suggest
adding a way to tell it to overwrite unversioned directories and files
with identical contents without also telling it to overwrite files
with differing content.

>> It is not. It may be marginally correct in your case,
>> however, Subversion has no way of knowing that the unversioned directory
>> it sees is in any way related to whatever is on the switched branch. It
>> needs user input; it cannot magically become "smart enough".

Don't forget that it was subversion, not the user, that created the
directory and abandoned it in the first place.   Yes, some of the
other tools the user uses may be equally dumb about leaving cruft
behind and confusing svn, but the user may not know the internals of
all the tools.

> If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back.
>
>
>> For example, consider a typical Java module which has "build.xml" file
>> and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and unrelated
>> module in their working copy, incidentally also calling it "A". Then
>> they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned thing
>> I have here is also called "A", I'm going to assume its the same as the
>> incoming directory, let's make it so." And in the next step: "Oh, I have
>> an unversioned file called build.xml, I'll just assume it's the same as
>> the incoming and merge changes in...." boom, instant merge conflict.
>
> Certainly if there are *file* conflicts then Subversion should complain loudly and not do anything automatically, however that was not the scenario the person who opened this thread posed.

I'd propose that file conflicts aren't really conflicts if the
contents are identical.   And that there should be a way to tell
subversion to go ahead and force overwrites of directories and
identical file contents without, at the same time, telling it to
clobber files with differing data.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Branko Čibej <br...@wandisco.com>]

On 24.08.2013 13:51, Ryan Schmidt wrote:
> On Aug 24, 2013, at 02:48, Branko Čibej wrote:
>> On 24.08.2013 03:44, Ryan Schmidt wrote:
>>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>>> I think it is the problem we've been discussing.  Leaving them means
>>>> you have to keep the containing directory, which becomes unversioned
>>>> as you switch away from the branch having it,
>>> Correct.
>>>
>>>> and then a conflict when
>>>> you switch back.
>>> *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.
>> You're assuming it is correct, in all cases, to silently make a
>> directory versioned because the incoming directory happens to have the
>> same name. It is not. It may be marginally correct in your case,
>> however, Subversion has no way of knowing that the unversioned directory
>> it sees is in any way related to whatever is on the switched branch. It
>> needs user input; it cannot magically become "smart enough".
> If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back.

Because a) that would mean the working copy would have to remember /all/
opereations that ever happend in its history, and b) it wouldn't work
anyway because even if we did a), there's still no way for the working
copy to know what happened outside of Subversion. And you're ignoring
the update case, which breaks your solution.

We surely have better things to do than invest man-years of time into
fixing a problem that goes away if you actually take the time to read
documentation.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Switching

[Ryan Schmidt <su...@ryandesign.com>]

On Aug 24, 2013, at 02:48, Branko Čibej wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>> I think it is the problem we've been discussing.  Leaving them means
>>> you have to keep the containing directory, which becomes unversioned
>>> as you switch away from the branch having it,
>> Correct.
>> 
>>> and then a conflict when
>>> you switch back.
>> *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.
> 
> You're assuming it is correct, in all cases, to silently make a
> directory versioned because the incoming directory happens to have the
> same name. It is not. It may be marginally correct in your case,
> however, Subversion has no way of knowing that the unversioned directory
> it sees is in any way related to whatever is on the switched branch. It
> needs user input; it cannot magically become "smart enough".

If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back.


> For example, consider a typical Java module which has "build.xml" file
> and two directories, "src" and "test". You add such a module called "A"
> on the branch. Someone else creates a completely different and unrelated
> module in their working copy, incidentally also calling it "A". Then
> they switch to the branch. What happens?
> 
> You're proposing that Subversion would say, "Oh, this unversioned thing
> I have here is also called "A", I'm going to assume its the same as the
> incoming directory, let's make it so." And in the next step: "Oh, I have
> an unversioned file called build.xml, I'll just assume it's the same as
> the incoming and merge changes in...." boom, instant merge conflict.

Certainly if there are *file* conflicts then Subversion should complain loudly and not do anything automatically, however that was not the scenario the person who opened this thread posed.

Re: Switching

[Branko Čibej <br...@wandisco.com>]

On 24.08.2013 03:44, Ryan Schmidt wrote:
> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>
>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>
>>>> I can't, off the top of my head, think of a scenario where it would be
>>>> harmful to replace an unversioned directory with a versioned instance,
>>>> leaving any unversioned local files that happen to be there alone.
>>> Leaving unversioned local files alone in a directory is not the problem.
>> I think it is the problem we've been discussing.  Leaving them means
>> you have to keep the containing directory, which becomes unversioned
>> as you switch away from the branch having it,
> Correct.
>
>> and then a conflict when
>> you switch back.
> *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.

You're assuming it is correct, in all cases, to silently make a
directory versioned because the incoming directory happens to have the
same name. It is not. It may be marginally correct in your case,
however, Subversion has no way of knowing that the unversioned directory
it sees is in any way related to whatever is on the switched branch. It
needs user input; it cannot magically become "smart enough".

For example, consider a typical Java module which has "build.xml" file
and two directories, "src" and "test". You add such a module called "A"
on the branch. Someone else creates a completely different and unrelated
module in their working copy, incidentally also calling it "A". Then
they switch to the branch. What happens?

You're proposing that Subversion would say, "Oh, this unversioned thing
I have here is also called "A", I'm going to assume its the same as the
incoming directory, let's make it so." And in the next step: "Oh, I have
an unversioned file called build.xml, I'll just assume it's the same as
the incoming and merge changes in...." boom, instant merge conflict.

It actually gets worse, because following your proposal, Subversion will
happily recurse in the same way into src and test -- the final result
being an unholy mess that you're going to have a fine time untangling,
not to mention that you just messed up the poor user's unversioned local
changes.

And of course, all of the above is not specific to switch -- but also to
update, when there are no branches involved.

So, yeah, it ain't gonna happen. You /do/ have the option to use
--force, but there's a reason why that isn't the default.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Switching

[Ryan Schmidt <su...@ryandesign.com>]

On Aug 23, 2013, at 13:31, Les Mikesell wrote:

> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
> 
>>> I can't, off the top of my head, think of a scenario where it would be
>>> harmful to replace an unversioned directory with a versioned instance,
>>> leaving any unversioned local files that happen to be there alone.
>> 
>> Leaving unversioned local files alone in a directory is not the problem.
> 
> I think it is the problem we've been discussing.  Leaving them means
> you have to keep the containing directory, which becomes unversioned
> as you switch away from the branch having it,

Correct.

> and then a conflict when
> you switch back.

*This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro <0p...@gmx.us> wrote:

>> I can't, off the top of my head, think of a scenario where it would be
>> harmful to replace an unversioned directory with a versioned instance,
>> leaving any unversioned local files that happen to be there alone.
>
> Leaving unversioned local files alone in a directory is not the problem.

I think it is the problem we've been discussing.  Leaving them means
you have to keep the containing directory, which becomes unversioned
as you switch away from the branch having it, and then a conflict when
you switch back.

> I've personally ran into scenarios where the local directory contained
> unversioned local files that obstruct a file that will be added by a
> switch/update/merge/what-have-you.

Don't think that's the case here.  These files are supposed to be
svn-ignored, so they should not have a copy in the repo.

> If the local file's content matches
> the content in the repository, then I think it is safe to simply replace
> the unversioned local file with the versioned file from the repository.

Yes, that would be handy - and harmless - as well.

> Often, the content has not been the same. It all depends on a lot of
> factors such as how it became unversioned, what has happened to the file
> while it was unversioned, etc. Replacing the content of the local file
> with the content in the repository looses local data.

Agreed, there is no reasonable way to handle this case automatically.
But it shouldn't happen as long as the clutter is never committed.

It is probably bad practice to default to letting cruft stay across
switches since your workspace would end up different than a fresh
checkout but it would be handy to have a way to force mostly-harmless
operations without overwriting any differing file data.

-- 
   Les Mikesell
      lesmikesell@gmail.com

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/23/13 10:34 AM, Les Mikesell wrote:
> I can't, off the top of my head, think of a scenario where it would be
> harmful to replace an unversioned directory with a versioned instance,
> leaving any unversioned local files that happen to be there alone.

Leaving unversioned local files alone in a directory is not the problem.
I've personally ran into scenarios where the local directory contained
unversioned local files that obstruct a file that will be added by a
switch/update/merge/what-have-you. If the local file's content matches
the content in the repository, then I think it is safe to simply replace
the unversioned local file with the versioned file from the repository.
Often, the content has not been the same. It all depends on a lot of
factors such as how it became unversioned, what has happened to the file
while it was unversioned, etc. Replacing the content of the local file
with the content in the repository looses local data. Merging the
unversioned content and the versioned content usually result in poor
merges (in the best case scenario) because there is no base revision to
use in the 3-way merge. I've seen merges like this get committed
accidentally and cause havoc. Of course, using the unversioned local
content instead of merging the content from the repository could
accidentally replace the entire contents of the file and this can
accidentally get committed as well. Subversion needs the user's help to
figure out what to do and marks these conflicts as tree conflicts.

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Fri, Aug 23, 2013 at 1:33 PM, Andrew Reedick
<An...@cbeyond.net> wrote:
>>
>> I can't, off the top of my head, think of a scenario where it would be
>> harmful to replace an unversioned directory with a versioned instance,
>> leaving any unversioned local files that happen to be there alone.
>> Other than maybe the chance that you'd accidentally commit them later,
>> but that is no different than if you had put the local files in after
>> the switch.  Am I missing something?   Is there a way to --force that
>> without also potentially --force'ing files that conflict to be
>> clobbered?
>>
>
> Dir permissions and ownership would change to that of the current user and umask and could create a security gap, but that probably falls under "if you're using --force, it's on your head".
>
> How are symlinks handled by switch --force?  It fails, or does it look at the target file/dir when deciding whether to replace it with a versioned object?
>
> How are hardlinks handled by switch --force?  Is the hardlinked file removed and replaced with a brand new file?  Or does switch --force work directly on the hardlinked file thus updating all the "copies"?
>
> On the windows side, would replacing a junction cause problems?
>

For this particular case, where the 'unversioned' directory was in
fact created by svn and abandoned instead of being deleted during a
switch to a branch without it, I don't think any of those scenarios
are possible.   But, you are right that in the general case svn would
have to check for special circumstances and raise conflicts if you
have done something weird.

-- 
   Les Mikesell
    lesmikesell@gmail.com

RE: Switching

[Andrew Reedick <An...@cbeyond.net>]

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Friday, August 23, 2013 1:34 PM
> To: Edwin Castro
> Cc: Subversion
> Subject: Re: Switching
> 
> 
> I can't, off the top of my head, think of a scenario where it would be
> harmful to replace an unversioned directory with a versioned instance,
> leaving any unversioned local files that happen to be there alone.
> Other than maybe the chance that you'd accidentally commit them later,
> but that is no different than if you had put the local files in after
> the switch.  Am I missing something?   Is there a way to --force that
> without also potentially --force'ing files that conflict to be
> clobbered?
> 

Dir permissions and ownership would change to that of the current user and umask and could create a security gap, but that probably falls under "if you're using --force, it's on your head".  

How are symlinks handled by switch --force?  It fails, or does it look at the target file/dir when deciding whether to replace it with a versioned object?

How are hardlinks handled by switch --force?  Is the hardlinked file removed and replaced with a brand new file?  Or does switch --force work directly on the hardlinked file thus updating all the "copies"?

On the windows side, would replacing a junction cause problems?

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Fri, Aug 23, 2013 at 11:17 AM, Edwin Castro <0p...@gmx.us> wrote:
>>>
>> I don't buy the argument about different histories: the pre-existing
>> directory doesn't have a subversion history, so from svn's point of
>> view there is no conflict.  What are the real, practical problems that
>> you know of or foresee with svn swich --force?
>>
>
> When objects do not have history, then subversion is in the position to
> try to decide what to do with content that already exists on the
> filesystem.

I can't, off the top of my head, think of a scenario where it would be
harmful to replace an unversioned directory with a versioned instance,
leaving any unversioned local files that happen to be there alone.
Other than maybe the chance that you'd accidentally commit them later,
but that is no different than if you had put the local files in after
the switch.  Am I missing something?   Is there a way to --force that
without also potentially --force'ing files that conflict to be
clobbered?

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/23/13 8:16 AM, Anders J. Munch wrote:
> Edwin Castro wrote:
>> I think the --force option is dangerous. Try it out but, in my opinion,
>> you should not use it.
> Why? Doesn't it perfectly solve the described problem?

The problem with --force, as the documentation points out, is that it
can make things versioned that were previously unversioned. Using a
concrete example, a *.sou file that was previously unversioned might
become versioned after a switch and then gets committed, accidentally,
into your respository.

> I had like so many others given up on switch, because cleaning up
> working copies prior to the switch was annoying busywork, an
> unnecessary risk (you might delete files that you wished you hadn't)
> and very easily forgotten, leading to a messed up working copy. But
> now I'm beginning to rethink that; I just have to remember to use
> --force with every svn switch.
>
> I don't buy the argument about different histories: the pre-existing
> directory doesn't have a subversion history, so from svn's point of
> view there is no conflict.  What are the real, practical problems that
> you know of or foresee with svn swich --force?
>

When objects do not have history, then subversion is in the position to
try to decide what to do with content that already exists on the
filesystem. It can't make reasonable decisions because there is no base
revision to use in the 3-way diff. Ultimately, the proper response is
for subversion to say "I can't add the file/directory/what-have-you
because there is something blocking my way". It then becomes the user's
responsibility to determine what to do. Thinking in the most general
sense, one solution for this scenario might work well for one individual
but not another. The prescribed solution might not even work reliably
every time that one individual sees this scenario. In order for
subversion to do the right thing it would need to be psychic. I'm afraid
subversion already takes the best possible action which is to require
user intervention.

--
Edwin G. Castro

Re: Switching

["Anders J. Munch" <aj...@flonidan.dk>]

Edwin Castro wrote:
> I think the --force option is dangerous. Try it out but, in my opinion,
> you should not use it.

Why? Doesn't it perfectly solve the described problem?

I had like so many others given up on switch, because cleaning up
working copies prior to the switch was annoying busywork, an
unnecessary risk (you might delete files that you wished you hadn't)
and very easily forgotten, leading to a messed up working copy. But
now I'm beginning to rethink that; I just have to remember to use
--force with every svn switch.

I don't buy the argument about different histories: the pre-existing
directory doesn't have a subversion history, so from svn's point of
view there is no conflict.  What are the real, practical problems that
you know of or foresee with svn swich --force?

regards, Anders

Re: Switching

[Edwin Castro <0p...@gmx.us>]

You said, and I quote, "There is a class library in one branch but not
in the other mixed with unversioned files that I can do nothing about."

I misread that statement to mean you had compiled output committed in
one branch. You seem to be trying to point out that the class library is
not compiled in the repository. The source code to the class library is.
OK, that's fine.

The point of fact is that there are "unversioned files that I can do
nothing about." A few of us are pointing out the potential problems that
occur when these unversioned files are important enough that they need
to be kept around. You say you "can do nothing about" the fact that the
unversioned files are important. I question whether there is really is
nothing you can do. Sometimes tools gently point out that there are
deficiencies elsewhere. We should not ignore them.

I think the --force option is dangerous. Try it out but, in my opinion,
you should not use it.

I think Philip Martin's suggestion is a better solution.

On 8/22/13 11:39 AM, John Maher wrote:
> You digress.  Not a single one of the compiled libraries lives within the versioned directories.  Please read the question before replying incorrectly.  It has nothing to do with code.  It has nothing to do with the build.  Please ask for clarification if you do not understand.  You gave a good suggestion with the force option.  Then you wandered off to completely irrelevant ramblings.  Should quit while you're ahead.
>
> -----Original Message-----
> From: Edwin Castro [mailto:0ptikGhost@gmx.us] 
> Sent: Thursday, August 22, 2013 2:30 PM
> To: users@subversion.apache.org
> Subject: Re: Switching
>
> On 8/22/13 10:54 AM, John Maher wrote:
>> This happens even if you do not do a build.  There is a class library in one branch but not the other mixed with unversioned files that I can do nothing about.
> Statements like this make me believe that build system is broken. I would expect the svn switch like problems on nearly any SCM you use that has the ability to switch a single working copy (or workspace, client,
> what-have-you) between branches. My knee jerk reaction in situations like this is to fix the build system.
>
> Are you sure there is nothing you can do? Perhaps you can suggests a simple fix like moving the versioned class library to a location that is always versioned. For example, instead of referencing a class library that lives in a bin/ directory it is better to keep the class library in a lib/ directory instead. Build output goes in the unversioned bin/ directory and versioned resources go in the lib/ directory.
>
> --
> Edwin G. Castro
>
>
>
>

RE: Switching

[John Maher <Jo...@rotair.com>]

You digress.  Not a single one of the compiled libraries lives within the versioned directories.  Please read the question before replying incorrectly.  It has nothing to do with code.  It has nothing to do with the build.  Please ask for clarification if you do not understand.  You gave a good suggestion with the force option.  Then you wandered off to completely irrelevant ramblings.  Should quit while you're ahead.

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

On 8/22/13 10:54 AM, John Maher wrote:
> This happens even if you do not do a build.  There is a class library in one branch but not the other mixed with unversioned files that I can do nothing about.

Statements like this make me believe that build system is broken. I would expect the svn switch like problems on nearly any SCM you use that has the ability to switch a single working copy (or workspace, client,
what-have-you) between branches. My knee jerk reaction in situations like this is to fix the build system.

Are you sure there is nothing you can do? Perhaps you can suggests a simple fix like moving the versioned class library to a location that is always versioned. For example, instead of referencing a class library that lives in a bin/ directory it is better to keep the class library in a lib/ directory instead. Build output goes in the unversioned bin/ directory and versioned resources go in the lib/ directory.

--
Edwin G. Castro

Re: Switching

[Edwin Castro <0p...@gmx.us>]

On 8/22/13 10:54 AM, John Maher wrote:
> This happens even if you do not do a build.  There is a class library in one branch but not the other mixed with unversioned files that I can do nothing about.

Statements like this make me believe that build system is broken. I
would expect the svn switch like problems on nearly any SCM you use that
has the ability to switch a single working copy (or workspace, client,
what-have-you) between branches. My knee jerk reaction in situations
like this is to fix the build system.

Are you sure there is nothing you can do? Perhaps you can suggests a
simple fix like moving the versioned class library to a location that is
always versioned. For example, instead of referencing a class library
that lives in a bin/ directory it is better to keep the class library in
a lib/ directory instead. Build output goes in the unversioned bin/
directory and versioned resources go in the lib/ directory.

--
Edwin G. Castro

RE: Switching

[John Maher <Jo...@rotair.com>]

This happens even if you do not do a build.  There is a class library in one branch but not the other mixed with unversioned files that I can do nothing about.

-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net] 
Sent: Thursday, August 22, 2013 1:48 PM
To: John Maher; Johan Corveleyn
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: RE: Switching



> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Thursday, August 22, 2013 1:34 PM
> To: Johan Corveleyn
> Cc: Thorsten Schöning; users@subversion.apache.org
> Subject: RE: Switching
> 
> 
> The problem isn't something in the way, the problem is something is 
> there when nothing is expected.  There is a directory in one branch 
> but not the other.  Subversion half empties it when switching to the 
> branch without the directory.  Then when switching back to the branch 
> where the directory lives it complains that it can not add it because 
> it is there.  But that very same directory was part of the branch that 
> is complaining that it can not add it because it is there.
> 

Okay, this isn't a svn issue.  This sounds more like a "I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace."  That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general.  

The whole "trunk, switch to B, switch back to trunk" directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.

RE: Switching

[Andrew Reedick <An...@cbeyond.net>]

> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Thursday, August 22, 2013 1:34 PM
> To: Johan Corveleyn
> Cc: Thorsten Schöning; users@subversion.apache.org
> Subject: RE: Switching
> 
> 
> The problem isn't something in the way, the problem is something is
> there when nothing is expected.  There is a directory in one branch but
> not the other.  Subversion half empties it when switching to the branch
> without the directory.  Then when switching back to the branch where
> the directory lives it complains that it can not add it because it is
> there.  But that very same directory was part of the branch that is
> complaining that it can not add it because it is there.
> 

Okay, this isn't a svn issue.  This sounds more like a "I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace."  That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general.  

The whole "trunk, switch to B, switch back to trunk" directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.

RE: Switching

[John Maher <Jo...@rotair.com>]

Thanks for the reply Johan.

I did not get your previous mail, thanks for re-stating it.  That is worth looking into.  I'll see how much I have to change to allow the alternate directories.  Maybe experiment keeping the trunk on the network for backup purposes and the branches local so as not to tax the backup.  The costs can really increase.


"If an unversioned directory is in the way, Subversion has no place where to put that data."

The problem isn't something in the way, the problem is something is there when nothing is expected.  There is a directory in one branch but not the other.  Subversion half empties it when switching to the branch without the directory.  Then when switching back to the branch where the directory lives it complains that it can not add it because it is there.  But that very same directory was part of the branch that is complaining that it can not add it because it is there.

What I mean by ignore is that subversion properly ignored deleting the directory because it had unversioned files in it.  But refused to ignore adding it.  There may be a good reason for that behavior, I just find it hard to believe that I am the only one who had this problem.  I'm betting that there is some unintuitive solution to this.

JM

-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com] 
Sent: Thursday, August 22, 2013 1:13 PM
To: John Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching

On Thu, Aug 22, 2013 at 5:48 PM, John Maher <Jo...@rotair.com> wrote:
> Actually I would call the problem the way I am using the tool.  Since no one has provided a better solution there may not be one.  ...
>

Did you read my previous mail in this thread? IMO a better solution in your case is not to use switch, but use dedicated checkouts for each branch. If you have to do this often (say multiple times a day), perhaps create a small script that takes away some of the typing of 'svn co $URL/branches/X'


On Thu, Aug 22, 2013 at 6:40 PM, John Maher <Jo...@rotair.com> wrote:
> I don't think you even tried Thorsten,
>
> I can easily.  There are actually several options.
>
> 1) When switching branches don't raise a conflict if all the files in the directory are in the global ignore list.  And if all that exists in a directory are files to be ignored it makes logical sense to ignore the parent directory.
>

What do you mean with "ignore"? By switching you asked Subversion to download all the data that's meant to be there. If an unversioned directory is in the way, Subversion has no place where to put that data. Do you mean SVN should just throw away your unversioned data?
That would go against one of SVN's prime directives, which is to try never to destroy any unversioned data. Those unversioned files may be very important to me (even if in the global-ignores list).

> 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list.
>
> 3) An OK-to-delete-if-in-conflict property could be created.
>

That might be possible (but this sounds *very* handwavy -- there are a lot of details in there, lots of edge cases), but that's a very dangerous flag, which makes it very much possible for people to shoot themselves in the foot. After implementing such a feature, I bet there will be more posts than yours, from people asking if they can get their data back.

> And I don't even know the tool well, if I knew it better I can come up with even better solutions.  I'm not going to bother listing any more alternatives, there are plenty.  Might as well wish I had a candy bar right now.  Its OK to wish, but it won't happen.  I'll bet any talented developer could come up with a solution if they tried.
>

Perhaps, but I can't (or at least, it would take me quite a bit of my rare free time). Perhaps someone else will jump in, but if you badly want this, I think you'll have to try describing a good (detailed) behavior yourself (and be prepared to patiently answer tough questions that may arise).

--
Johan

Re: Switching

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Aug 22, 2013 at 5:48 PM, John Maher <Jo...@rotair.com> wrote:
> Actually I would call the problem the way I am using the tool.  Since no one has provided a better solution there may not be one.  ...
>

Did you read my previous mail in this thread? IMO a better solution in
your case is not to use switch, but use dedicated checkouts for each
branch. If you have to do this often (say multiple times a day),
perhaps create a small script that takes away some of the typing of
'svn co $URL/branches/X'


On Thu, Aug 22, 2013 at 6:40 PM, John Maher <Jo...@rotair.com> wrote:
> I don't think you even tried Thorsten,
>
> I can easily.  There are actually several options.
>
> 1) When switching branches don't raise a conflict if all the files in the directory are in the global ignore list.  And if all that exists in a directory are files to be ignored it makes logical sense to ignore the parent directory.
>

What do you mean with "ignore"? By switching you asked Subversion to
download all the data that's meant to be there. If an unversioned
directory is in the way, Subversion has no place where to put that
data. Do you mean SVN should just throw away your unversioned data?
That would go against one of SVN's prime directives, which is to try
never to destroy any unversioned data. Those unversioned files may be
very important to me (even if in the global-ignores list).

> 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list.
>
> 3) An OK-to-delete-if-in-conflict property could be created.
>

That might be possible (but this sounds *very* handwavy -- there are a
lot of details in there, lots of edge cases), but that's a very
dangerous flag, which makes it very much possible for people to shoot
themselves in the foot. After implementing such a feature, I bet there
will be more posts than yours, from people asking if they can get
their data back.

> And I don't even know the tool well, if I knew it better I can come up with even better solutions.  I'm not going to bother listing any more alternatives, there are plenty.  Might as well wish I had a candy bar right now.  Its OK to wish, but it won't happen.  I'll bet any talented developer could come up with a solution if they tried.
>

Perhaps, but I can't (or at least, it would take me quite a bit of my
rare free time). Perhaps someone else will jump in, but if you badly
want this, I think you'll have to try describing a good (detailed)
behavior yourself (and be prepared to patiently answer tough questions
that may arise).

-- 
Johan

RE: Switching

[John Maher <Jo...@rotair.com>]

I don't think you even tried Thorsten,

I can easily.  There are actually several options.

1) When switching branches don't raise a conflict if all the files in the directory are in the global ignore list.  And if all that exists in a directory are files to be ignored it makes logical sense to ignore the parent directory.

2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list.

3) An OK-to-delete-if-in-conflict property could be created.

And I don't even know the tool well, if I knew it better I can come up with even better solutions.  I'm not going to bother listing any more alternatives, there are plenty.  Might as well wish I had a candy bar right now.  Its OK to wish, but it won't happen.  I'll bet any talented developer could come up with a solution if they tried.



-----Original Message-----
From: Thorsten Schöning [mailto:tschoening@am-soft.de] 
Sent: Thursday, August 22, 2013 12:21 PM
To: users@subversion.apache.org
Subject: Re: Switching

Guten Tag John Maher,
am Donnerstag, 22. August 2013 um 17:48 schrieben Sie:

> Actually I would call the problem the way I am using the tool.
> Since no one has provided a better solution there may not be one. 
> Perhaps no one considered switching between branches where there could 
> exist a directory with unversioned files in one and not the other.  I 
> don't know.  Maybe no one wanted to make it work since they never 
> needed that feature.  I don't know.  After reading tons of material on 
> subversion I thought it would be good to keep development for 
> individual features in separate branches.  But the cost is easily out 
> weighing the benefit.

How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about?

I don't see how this problem can be solved by any tool.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Switching

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag John Maher,
am Donnerstag, 22. August 2013 um 17:48 schrieben Sie:

> Actually I would call the problem the way I am using the tool.
> Since no one has provided a better solution there may not be one. 
> Perhaps no one considered switching between branches where there
> could exist a directory with unversioned files in one and not the
> other.  I don't know.  Maybe no one wanted to make it work since
> they never needed that feature.  I don't know.  After reading tons
> of material on subversion I thought it would be good to keep
> development for individual features in separate branches.  But the
> cost is easily out weighing the benefit.

How would you like Subversion to work in your case? From my
understanding it breaks down to something generated some files for
some reason in one of your branches and now you want to switch form
that branch to another which does not contain the base directory of
the generated files. What should subversion do with your generated
files it doesn't know anything about?

I don't see how this problem can be solved by any tool.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: Switching

[John Maher <Jo...@rotair.com>]

Thanks for the reply Les.

Actually I would call the problem the way I am using the tool.  Since no one has provided a better solution there may not be one.  Perhaps no one considered switching between branches where there could exist a directory with unversioned files in one and not the other.  I don't know.  Maybe no one wanted to make it work since they never needed that feature.  I don't know.  After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches.  But the cost is easily out weighing the benefit.

And one of the files I am ignoring is user settings which is required for testing.  Deleting that file would just introduce more trouble causing the user to repeatedly re-enter settings to test code.  The output is already directed away to a development directory.  I see no way to delete the intermediate files which would get constantly re-created anyway and would not solve the problem because the user settings file would still cause the same issue.  And the developers need their own settings.

Before I started trying to learn the branching (which I didn't even get to yet since simply switching is causing so much grief) I would jot down on a piece of paper which projects affected which feature and do all the development in the trunk then only put in production what was needed.  This worked.  It just seems strange to have to keep notes on a piece of paper which modules are for which feature using source code control software.

But if that's how subversion works, then that's how it works.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com] 
Sent: Thursday, August 22, 2013 11:00 AM
To: John Maher
Cc: Andrew Reedick; Thorsten Schöning; Subversion help
Subject: Re: Switching

On Thu, Aug 22, 2013 at 6:30 AM, John Maher <Jo...@rotair.com> wrote:
>
> @Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.

Your problem is not so much that svn doesn't deleted the unversioned 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 simplest of enhancements.

Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content?

> I was hoping to find what others seem to praise, but have continually come up empty handed.  I'll check stackoverflow before I give up.

If the big picture is including library components and their containing directories in some versions and not others, the simple solution might be to give the components their own location in the repository (or a different one) and pull them in only as needed with
svn externals.   But, I think you still have to clean up the
unversioned clutter so a switch can remove the directory when it is
not wanted.   A slightly different approach is to version the built
component binaries and access them with externals, but that has its own issues in multi-platform scenarios.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Les Mikesell <le...@gmail.com>]

On Thu, Aug 22, 2013 at 6:30 AM, John Maher <Jo...@rotair.com> wrote:
>
> @Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.

Your problem is not so much that svn doesn't deleted the unversioned
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 simplest of enhancements.

Don't your build tools have commands to remove any spurious files
they've created or some equivalent of 'make clean' that you can run to
remove the clutter in a non-tedious way so that svn switch is free to
work correctly with the versioned content?

> I was hoping to find what others seem to praise, but have continually come up empty handed.  I'll check stackoverflow before I give up.

If the big picture is including library components and their
containing directories in some versions and not others, the simple
solution might be to give the components their own location in the
repository (or a different one) and pull them in only as needed with
svn externals.   But, I think you still have to clean up the
unversioned clutter so a switch can remove the directory when it is
not wanted.   A slightly different approach is to version the built
component binaries and access them with externals, but that has its
own issues in multi-platform scenarios.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Switching

[Johan Corveleyn <jc...@gmail.com>]

On Thu, Aug 22, 2013 at 1:30 PM, John Maher <Jo...@rotair.com> wrote:
> Thanks for your replies Andrew and Thorsten.
>
>
> @Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.  But it seems the only answer is a tedious and manual process for the simplest of enhancements.
>
> I was hoping to find what others seem to praise, but have continually come up empty handed.  I'll check stackoverflow before I give up.
>

The problems you are seeing here are the main reason why I (and some
other users on this list) try to avoid 'switch', and instead use
dedicated working copies for the different branches. Like you have
seen, it's just far too likely for the different 'variants' to step on
each other's toes (e.g. with generated files being in the way).

Another advantage of using different checkouts is that you can
immediately see (from the local directory name) in which branch you're
working. Leads to less incidents of the type 'oops, committed to the
wrong branch'.

Except for extremely large working copies, disk space is usually cheap
in comparison to the wasted time when you encounter such issues.
Perhaps the initial checkout of each of the working copies takes some
time, but that's mostly a one-time cost (one time per branch ... so it
depends a bit on how many branches or how often you branch).

I suggest you try to adapt your workflow to work with separate working copies.

(This does not mean that 'switch' is completely useless -- I still use
it for small ad-hoc things. It depends, YMMV. If you use it in a
structural way in your workflow, I think it's best to avoid too
complex working copies with perhaps local modifications, especially
when there's a risk of debris being left behind).

-- 
Johan

RE: Switching

[John Maher <Jo...@rotair.com>]

Thanks for your replies Andrew and Thorsten.  


@Andrew there is no need for a svn copy.  I do not want to copy a feature 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 to hear how others may have solved the same problem.  But it seems the only answer is a tedious and manual process for the simplest of enhancements.

I was hoping to find what others seem to praise, but have continually come up empty handed.  I'll check stackoverflow before I give up.

Thanks anyway
JM

-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net] 
Sent: Tuesday, August 20, 2013 4:02 PM
To: John Maher; Subversion help
Subject: RE: Switching



> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Tuesday, August 20, 2013 1:33 PM
> To: Andrew Reedick; Subversion help
> Subject: RE: Switching
> 
> Thanks for your reply.  I agree it does not make sense.  But it is 
> reproducible.  The dir trees are NOT identical because one branch has 
> a library that the other does not.  In normal use I would expect the 
> branches to differ.  And I assure you one of the branches does not 
> have the directory causing the trouble, I checked on the server.
> 
> So the branches are different and it appears impossible to switch 
> between them without conflicts.
> 
> For example, when I switch to branch P it switches OK.  An svn status 
> on the problem directory shows it with a '?'.  Then I switch to branch 
> E and get a conflict.  It says "local unversioned, incoming add upon 
> switch".  The local should be unversioned, it is not part of branch P.
> I do not know why the directory did not get deleted during the switch.
> An svn status shows the directory marked for deletion.  So in one 
> instance of time I get a message of a directory that is unversioned, 
> incoming add, marked for deletion.

When removing dirs, switch will not delete local/private/unversioned files.  If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it.  That's mostly likely why you see a '?' after the switch.

Ex:
1. 'this_dir' exists in current workspace as a versioned dir tree.
2. 'this_dir' does NOT exist in branch P.
3.  touch this_dir/hello_world.txt
3.  svn switch ^/branches/P
4.  svn status:  " ?       this_dir"
The only file under "this_dir" will be hello_world.txt.  All other versioned files/dirs will have been removed.

> 
> Svn revert does not do anything useful.  So I then issue svn resolve 
> -- accept working UI_Email where UI_Email is the directory causing the 
> problems.  This clears the conflict.
> 
> Then I switch to branch P.  Then is says "local delete, incoming 
> delete".  Why it has a local delete is beyond me.  That folder is part 
> of the branch, I want it there and never issued a delete.  But 
> subversion did.  So I resolve this conflict the same as the last one 
> and switch back to branch E.  You guessed it, conflict again.

You shot yourself in the foot.  =)

The local copy of the dir prevented switch from running the add.  (Switch wasn't able to pull in the versioned copy of the dir.)  Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P.  When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively "deleted", you wound up telling svn to delete the file from branch P.

Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict.


> 
> So I resolve the conflict then commit and decide to let subversion 
> delete the directory (I have a backup because I've lost code to 
> subversion before).  So now my code is gone.  I delete the directory 
> with supporting files.  Then I switch to branch P.  Success for now (I 
> know failure is just a matter of time).

You can recover the deleted versioned dirs and files via peg revisions.  http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect

 
> Then I switch to branch E.  No conflict.  But I won't get my hopes up 
> yet, I still do not have the new library included which was the whole 
> reason for creating the branch in the first place.

Right.  You deleted the dir from branch P.  And you deleted the local/private files/tree as well.  Thus no conflict with branch E.

However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.)  (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.)



> So I copy over the
> directory and do a svn add then commit.  Then I can switch to branch P.

Argh.  No, no, no.  That creates "evil twins".  What you should have done was 'svn copy svn://..../some_dir@1234 some_dir" to add the dir back in.  When you run 'svn add' you create brand new objects with no history.  Evil twins break merging.  



> This is where the problem arises.  Subversion deletes the files but 
> not the directory because it contains files that do not belong in 
> subversion.  I have no control over this as the compiler puts them 
> there.  They are on the global ignore list.

Svn switch won't delete your local/private files because that would be rude, where rude equals "destroying the user's files."  So if you're switching, you need to manage private/local files.  Maybe run 'make clean' (assuming you have a clean option) before switching?  Or tweak your build script to put all build output in its own dir, instead of putting output in the versioned dirs?

RE: Switching

[Andrew Reedick <An...@cbeyond.net>]

> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Tuesday, August 20, 2013 1:33 PM
> To: Andrew Reedick; Subversion help
> Subject: RE: Switching
> 
> Thanks for your reply.  I agree it does not make sense.  But it is
> reproducible.  The dir trees are NOT identical because one branch has a
> library that the other does not.  In normal use I would expect the
> branches to differ.  And I assure you one of the branches does not have
> the directory causing the trouble, I checked on the server.
> 
> So the branches are different and it appears impossible to switch
> between them without conflicts.
> 
> For example, when I switch to branch P it switches OK.  An svn status
> on the problem directory shows it with a '?'.  Then I switch to branch
> E and get a conflict.  It says "local unversioned, incoming add upon
> switch".  The local should be unversioned, it is not part of branch P.
> I do not know why the directory did not get deleted during the switch.
> An svn status shows the directory marked for deletion.  So in one
> instance of time I get a message of a directory that is unversioned,
> incoming add, marked for deletion.

When removing dirs, switch will not delete local/private/unversioned files.  If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it.  That's mostly likely why you see a '?' after the switch.

Ex:
1. 'this_dir' exists in current workspace as a versioned dir tree.
2. 'this_dir' does NOT exist in branch P.
3.  touch this_dir/hello_world.txt
3.  svn switch ^/branches/P
4.  svn status:  " ?       this_dir"
The only file under "this_dir" will be hello_world.txt.  All other versioned files/dirs will have been removed.

> 
> Svn revert does not do anything useful.  So I then issue svn resolve --
> accept working UI_Email where UI_Email is the directory causing the
> problems.  This clears the conflict.
> 
> Then I switch to branch P.  Then is says "local delete, incoming
> delete".  Why it has a local delete is beyond me.  That folder is part
> of the branch, I want it there and never issued a delete.  But
> subversion did.  So I resolve this conflict the same as the last one
> and switch back to branch E.  You guessed it, conflict again.

You shot yourself in the foot.  =)

The local copy of the dir prevented switch from running the add.  (Switch wasn't able to pull in the versioned copy of the dir.)  Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P.  When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively "deleted", you wound up telling svn to delete the file from branch P.

Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict.


> 
> So I resolve the conflict then commit and decide to let subversion
> delete the directory (I have a backup because I've lost code to
> subversion before).  So now my code is gone.  I delete the directory
> with supporting files.  Then I switch to branch P.  Success for now (I
> know failure is just a matter of time).

You can recover the deleted versioned dirs and files via peg revisions.  http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect

 
> Then I switch to branch E.  No conflict.  But I won't get my hopes up
> yet, I still do not have the new library included which was the whole
> reason for creating the branch in the first place.  

Right.  You deleted the dir from branch P.  And you deleted the local/private files/tree as well.  Thus no conflict with branch E.

However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.)  (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.)



> So I copy over the
> directory and do a svn add then commit.  Then I can switch to branch P.

Argh.  No, no, no.  That creates "evil twins".  What you should have done was 'svn copy svn://..../some_dir@1234 some_dir" to add the dir back in.  When you run 'svn add' you create brand new objects with no history.  Evil twins break merging.  



> This is where the problem arises.  Subversion deletes the files but not
> the directory because it contains files that do not belong in
> subversion.  I have no control over this as the compiler puts them
> there.  They are on the global ignore list.

Svn switch won't delete your local/private files because that would be rude, where rude equals "destroying the user's files."  So if you're switching, you need to manage private/local files.  Maybe run 'make clean' (assuming you have a clean option) before switching?  Or tweak your build script to put all build output in its own dir, instead of putting output in the versioned dirs?

Re: Switching

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag John Maher,
am Dienstag, 20. August 2013 um 19:33 schrieben Sie:

> For example, when I switch to branch P it switches OK.

Where did you switch from? Does this branch contain the directory
which is responsible for the later mentioned error message? It has
been created by someone of course, either by svn because it's part of
branch or by something other like a build tool.

> An svn
> status on the problem directory shows it with a '?'.  Then I switch
> to branch E and get a conflict.  It says "local unversioned,
> incoming add upon switch".

Which is correct behavior as the director is present, but not versioned.

> The local should be unversioned, it is
> not part of branch P. I do not know why the directory did not get
> deleted during the switch.

Surely because it contained unversioned data itself and therefor
couldn't be deleted by svn as it tries to never delete unversioned
data.

> Svn revert does not do anything useful.  So I then issue svn
> resolve --accept working UI_Email where UI_Email is the directory
> causing the problems.  This clears the conflict.

Of course, that's what resolve is meant for ;-), but the interesting
thing is the data in the directory. It may not contain all the files
and dirs need from your branch E where the directory is versioned in.

> Then I switch to branch P.  Then is says "local delete, incoming
> delete".  Why it has a local delete is beyond me.

This could be because your conflict resolution which may be missing
data which should be present in the director yin branch E, an is not
in your local working copy. This means something has changed but
didn't get committed because you switched instead of first committing
the changes from your conflict resolution.

> So I resolve the conflict then commit and decide to let subversion
> delete the directory (I have a backup because I've lost code to
> subversion before).

You never lose code unless you lose your repo, the only thing may be
that you don't know how to revert to older revisions. ;-) And yes, I
often have the same problem using the console applications and prefer
using Tortoise instead in those cases.

> Then I switch to branch E.  No conflict.

Of course, because the directory is missing, which is different to
what you have described in the start: You switched to branch P from
some other branch, which contained the directory and it surely did
contain unversioned files which prevented svn from deleting the
directory on switching to branch P.

> But I won't get my hopes
> up yet, I still do not have the new library included which was the
> whole reason for creating the branch in the first place.  So I copy
> over the directory and do a svn add then commit.  Then I can switch
> to branch P.  This is where the problem arises.  Subversion deletes
> the files but not the directory because it contains files that do
> not belong in subversion.

That's the info which should have been in the first mail and the start
of this one. :-)

> I have no control over this as the
> compiler puts them there.  They are on the global ignore list.

And subversion can't know how important those files are for you and
therefor can't just delete them. This problem is up to you, you need to
delete them on your own after switching to branch P if you don't need
the directory in your working copy.

> My question is how to properly handle this?  Or is branching
> unusable in this situation with out the extra hassle?

As subversion can't know what to do with unversioned files, it leaves
them as they are where they are. It is up to you to clean up your
working copy in such a way that it doesn't contain any mess which
prevents you from switching between different branches.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: Switching

[John Maher <Jo...@rotair.com>]

Thanks for your reply.  I agree it does not make sense.  But it is reproducible.  The dir trees are NOT identical because one branch has a library that the other does not.  In normal use I would expect the branches to differ.  And I assure you one of the branches does not have the directory causing the trouble, I checked on the server.

So the branches are different and it appears impossible to switch between them without conflicts.

For example, when I switch to branch P it switches OK.  An svn status on the problem directory shows it with a '?'.  Then I switch to branch E and get a conflict.  It says "local unversioned, incoming add upon switch".  The local should be unversioned, it is not part of branch P.  I do not know why the directory did not get deleted during the switch.  An svn status shows the directory marked for deletion.  So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion.

Svn revert does not do anything useful.  So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems.  This clears the conflict.

Then I switch to branch P.  Then is says "local delete, incoming delete".  Why it has a local delete is beyond me.  That folder is part of the branch, I want it there and never issued a delete.  But subversion did.  So I resolve this conflict the same as the last one and switch back to branch E.  You guessed it, conflict again.

So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before).  So now my code is gone.  I delete the directory with supporting files.  Then I switch to branch P.  Success for now (I know failure is just a matter of time).

Then I switch to branch E.  No conflict.  But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place.  So I copy over the directory and do a svn add then commit.  Then I can switch to branch P.  This is where the problem arises.  Subversion deletes the files but not the directory because it contains files that do not belong in subversion.  I have no control over this as the compiler puts them there.  They are on the global ignore list.

Now when I switch the conflict returns.  Nothing in the book explains how to handle this.  Searching comes up with all kinds of irrelevant stuff and unanswered questions.

My question is how to properly handle this?  Or is branching unusable in this situation with out the extra hassle?

Thanks JM







-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net] 
Sent: Tuesday, August 20, 2013 10:17 AM
To: John Maher; Subversion help
Subject: RE: Switching


> From: John Maher [mailto:JohnM@rotair.com] 
> Sent: Monday, August 19, 2013 1:31 PM
> To: Subversion help
> Subject: Switching
>
> Hello,
>
> I want to thank all who have been helpful.  I have gotten my test project to merge branches successfully.  Now I am trying it on our production code and wish to make sure I am not making any mistakes.
>
> I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory.   I have created two branches for two new features.  One feature extends an existing library.  The other feature adds a new library as well as extending an existing one.  When I switch I create a conflict because the directory exists in one branch and not the other:

That doesn't make sense.  If you branched (i.e. created copies of a baseline) then the dir trees should be identical.  Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too.  This happens if you 'svn add' the same dir in both branches.  Example:
Bad, causes conflict:  
    svn add ^/branches/foo/new_dir
    svn add ^/branches/bar/new_dir
Good:
    Svn add ^/branches/foo/new_dir
    cd to bar workspace; svn copy ^/branches/foo/new_dir .
It could also happen if you renamed/moved the same dir in both branches.


> local unversioned, incoming add upon switch

This sounds like you have a normal, unversioned directory in the workspace.  As part of the switch, svn wants to add a versioned dir of the same name to your workspace.  You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded.  I would 'svn revert -R' the entire workspace[1], rename the normal, local dir, and re-run the switch.  And figure out why you have a normal, unversioned copy of the dir in the first place.


> This may or may not be what is supposed to happen, that would be the first thing I would like to know.  How to fix it would be the second thing that I would like to know.  According to the help of the resolve command says:
> 
> So I tried svn resolve -accept working LibraryDirectory but I believe that was a mistake because then the directory was marked "Delete" which is not what I wanted.  Does anyone know what is the proper response?

Meh.  Resolving tree conflicts is a bit of a manual process.  IIRC, to resolve it, you would need to 
1) rename the normal, local dir, and
2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually implement the add.  ('svn switch' failed the add so you need to reproduce the add manually.)
3) 'svn resolve' the dir.
Which is why I recommend just reverting[1] the switch, renaming the dir and re-running the switch.

The main takeaway is that resolving tree conflicts isn't as easy as resolving file conflicts.  File conflicts let you use the 'mine-full', 'theirs-full', etc. options, but tree conflicts do not.  Fixing tree conflicts requires fixing up the tree in the workspace yourself and then using 'svn resolve --accept working' to tell subversion that the tree is now in the state you want.  In other words, you have to manually implement 'theirs-full'.


> I did not want to lose the library from the working copy so I switched back to the other branch and then switch back.  Now it says:

> local delete, incoming delete upon switch

You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your workspace.  However, the current 'svn switch' also wants to run 'svn delete some_dir'.  So svn switch is complaining that it can't delete the dir because it's already flagged for deletion.   =/


> It seems I did something wrong.  My next step would be to add the library back, but that may not be the best response.  Any suggestions?

It sounds like you mangled the switch with too many hacks while trying to fix it, i.e. the workspace is a mess.  Just 'svn revert -R'[1], then 'svn status' to make sure that there are no local/private files that could muck up the switch.

The thing to remember is that svn is replaying changes on top of your workspace.  It walks the revisions, and for each revision, applies that revision's changes to the workspace.  So if you're applying 10 revisions' worth of changes and the second revision breaks the switch/merge with a tree conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn revert, etc.), resolve it, and then re-run the switch/merge to apply the renaming 8 revisions.



[1] Before you run 'svn revert -R', run 'svn status' to make sure you don't have any modified, uncommitted files that you really care about.  Revert will delete those changes.

RE: Switching

[Andrew Reedick <An...@cbeyond.net>]

> From: John Maher [mailto:JohnM@rotair.com] 
> Sent: Monday, August 19, 2013 1:31 PM
> To: Subversion help
> Subject: Switching
>
> Hello,
>
> I want to thank all who have been helpful.  I have gotten my test project to merge branches successfully.  Now I am trying it on our production code and wish to make sure I am not making any mistakes.
>
> I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory.   I have created two branches for two new features.  One feature extends an existing library.  The other feature adds a new library as well as extending an existing one.  When I switch I create a conflict because the directory exists in one branch and not the other:

That doesn't make sense.  If you branched (i.e. created copies of a baseline) then the dir trees should be identical.  Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too.  This happens if you 'svn add' the same dir in both branches.  Example:
Bad, causes conflict:  
    svn add ^/branches/foo/new_dir
    svn add ^/branches/bar/new_dir
Good:
    Svn add ^/branches/foo/new_dir
    cd to bar workspace; svn copy ^/branches/foo/new_dir .
It could also happen if you renamed/moved the same dir in both branches.


> local unversioned, incoming add upon switch

This sounds like you have a normal, unversioned directory in the workspace.  As part of the switch, svn wants to add a versioned dir of the same name to your workspace.  You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded.  I would 'svn revert -R' the entire workspace[1], rename the normal, local dir, and re-run the switch.  And figure out why you have a normal, unversioned copy of the dir in the first place.


> This may or may not be what is supposed to happen, that would be the first thing I would like to know.  How to fix it would be the second thing that I would like to know.  According to the help of the resolve command says:
> 
> So I tried svn resolve -accept working LibraryDirectory but I believe that was a mistake because then the directory was marked "Delete" which is not what I wanted.  Does anyone know what is the proper response?

Meh.  Resolving tree conflicts is a bit of a manual process.  IIRC, to resolve it, you would need to 
1) rename the normal, local dir, and
2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually implement the add.  ('svn switch' failed the add so you need to reproduce the add manually.)
3) 'svn resolve' the dir.
Which is why I recommend just reverting[1] the switch, renaming the dir and re-running the switch.

The main takeaway is that resolving tree conflicts isn't as easy as resolving file conflicts.  File conflicts let you use the 'mine-full', 'theirs-full', etc. options, but tree conflicts do not.  Fixing tree conflicts requires fixing up the tree in the workspace yourself and then using 'svn resolve --accept working' to tell subversion that the tree is now in the state you want.  In other words, you have to manually implement 'theirs-full'.


> I did not want to lose the library from the working copy so I switched back to the other branch and then switch back.  Now it says:

> local delete, incoming delete upon switch

You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your workspace.  However, the current 'svn switch' also wants to run 'svn delete some_dir'.  So svn switch is complaining that it can't delete the dir because it's already flagged for deletion.   =/


> It seems I did something wrong.  My next step would be to add the library back, but that may not be the best response.  Any suggestions?

It sounds like you mangled the switch with too many hacks while trying to fix it, i.e. the workspace is a mess.  Just 'svn revert -R'[1], then 'svn status' to make sure that there are no local/private files that could muck up the switch.

The thing to remember is that svn is replaying changes on top of your workspace.  It walks the revisions, and for each revision, applies that revision's changes to the workspace.  So if you're applying 10 revisions' worth of changes and the second revision breaks the switch/merge with a tree conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn revert, etc.), resolve it, and then re-run the switch/merge to apply the renaming 8 revisions.



[1] Before you run 'svn revert -R', run 'svn status' to make sure you don't have any modified, uncommitted files that you really care about.  Revert will delete those changes.

Re: Switching

[Philip Martin <ph...@wandisco.com>]

John Maher <Jo...@rotair.com> writes:

> I use one folder for my source code (all branches) mainly because of
> vendor requirements the code must be run from the same directory.  I
> have created two branches for two new features.  One feature extends
> an existing library.  The other feature adds a new library as well as
> extending an existing one.  When I switch I create a conflict because
> the directory exists in one branch and not the other:
>
> local unversioned, incoming add upon switch
>
> This may or may not be what is supposed to happen, that would be the
> first thing I would like to know.  How to fix it would be the second
> thing that I would like to know.

svnadmin create repo
svn -mm mkdir file://`pwd`/repo/A
svn -mm cp file://`pwd`/repo/A ^/B
svn -mm mkdir file://`pwd`/repo/B/X
svn co file://`pwd`/repo/B wc
touch wc/X/f                        # an unversioned file

Switch can't remove wc/X because wc/X/f exists:

svn sw ^/A wc
svn st wc
?       wc/X

The unversioned wc/X will cause a conflict when switching back:

svn sw ^/B wc --accept postpone
svn st wc
D     C wc/X
      >   local dir unversioned, incoming dir add upon switch
?       wc/X/f
Summary of conflicts:
  Tree conflicts: 1

The conflict can be resolved by reverting the delete:

svn revert -R wc/X
svn st wc
?       wc/X/f

The original unversioned wc/X/f has been preserved across both switches.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*