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:jcor...@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


Reply via email to