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
