On Mon, Feb 18, 2008 at 10:09:09PM -0000, Robert Collins wrote: > I understand svn's behaviour here. But bzr is not svn, and the behaviour > of bzr-svn in this situation is consistent with the behaviour bzr itself > would show if your homedir was versioned. So it is entirely irrelevant > how the svn UI behaves - because you're not using the svn UI.
I understand that bzr is not svn, and with all due respect I do not think my argument is based on how the svn *UI* behaves; it was just a convenient demonstration. The fact is that bzr+bzr-svn is interpreting this directory as part of an svn *working tree*. In this case it needs to follow the svn rules for what an svn working tree is, and it is not doing so. Note that svn doesn't say "you must add the parent directory first", but "this is not a working copy". As a user I find this distinction relevant. I behave differently when operating on files in working copies from how I behave when operating on files outside them. > If bzr was svn I would agree with you. The more I think about this the > more 'its operating as designed' as far as I can tell. 'bzr st' in an > unversioned subdir of a bzr tree will give that trees status. If the > tree happens to be a foreign tree the end user behaviour should be the > same, and bzr-svn is doing the right thing. While I do think I (now) understand where you're coming from in trying to make bzr work the same way regardless of the backend implementation, I'm afraid I still cannot agree with you here. I expect bzr-svn to operate on svn working trees et al except using the bzr UI. In this respect it is failing by treating something as an svn working tree when it simply is not, according to the conventions for what counts as an svn working tree. Who gets to decide those conventions? Who else but Subversion? Again, it is not the bzr rules for what is a working tree that should be relevant here; when trying to guess whether something is a foreign tree bzr must follow the foreign system's rules. If it said that it only counted as a foreign tree if it had a .bzr/foreign file it would be wrong too, only much more obviously so. In this case it's getting it nearly right except that it has false positives. > Its a shame you needed to do this. This may indicate that the bzr UI in > unversioned subdirectories is inappropriate, rather than being a bzr-svn > specific issue. I think it is inappropriate in the case of svn working trees, because it breaks the user expectation of how unversioned subdirectories of svn working trees behave; that is, they're left alone unless you explicitly add the directories. I set up this svn home directory arrangement a long time ago. When I set it up, I knew how svn behaved with regard to unversioned directories, and took advantage of it; I only added the directories I wanted to be part of this repository, with the expectation that I would deal with items in other subdirectories in other ways. From my perspective, bzr-svn has come along several years later, declared that it knows how this all works, and proceeded to define it in a different way that causes inconvenience. I don't think this is OK. You can only say that it's working by design if yours is the only design that applies. > if thats the case we can look at how to change it (and from there how > to tweak the interface so bzr-svn doesn't trigger network activity etc > like it is). I do think that 'bzr init', 'bzr branch', and so on should not behave differently if they happen to be in an svn working tree. A .svn control directory can't act as a bzr repository (as far as I know, anyway ...) and so there's no reason for commands that create branches to take any account of it. This is the major problem because the only ways around it are brutal (removing bzr-svn) or non-obvious (creating a stub .bzr). Separately (although if the branch creation commands were fixed then this would be less of an issue, because it would only be triggered by accidents), I think I would find it very surprising if 'bzr add' several subdirectories down decided to add a whole directory tree just because I keep some dotfiles in my home directory in svn; as far as I'm concerned I am not in the svn working tree, and so bzr's behaviour is unexpected. Having to clean up after this would be disconcerting. If I kept my home directory in bzr, I would very probably look at it differently because I know from where bzr keeps its control directory and from various other explicitly documented facts such as the behaviour of repositories that it versions the whole tree. But, because I keep it in svn, I have a different set of expectations based on well-known facts about how the svn working tree is laid out. When operating within an unversioned subdirectory of an svn working tree, I'd rather that 'bzr add' returned an error. I don't think this is (or should be) a property of the UIs; it is a property of the working tree layout. I appreciate that 'bzr add' *can* do this in unversioned subdirectories of svn working trees, but I don't think that this means it should. Thanks for your consideration. -- Colin Watson [EMAIL PROTECTED] -- bzr-svn is irritating when in a (non-svn) subdirectory of an svn working tree https://bugs.launchpad.net/bugs/192743 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
