On Wed, 2008-02-20 at 11:11 +0000, Colin Watson wrote: > 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.
And bzr doesn't have this distinction in its UI at the moment. > > 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? For an unversioned, unignored subtree of a working tree I think it is a UI decision; because it affects how people interact with their UI, and we don't want people using bzr-svn to have to remember 'I'm using svn over _here_, I need to do X, Y and Z differently'. bzr-svn is meant to be as seamless as possible. > > 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 think we need to address this issue; I think that what it actually points at is a weakness in the bzr UI which needs discussion. > 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. Given that the bzr design was created post svn's existence, we _can_ say that this is by design. That doesn't mean its correct :). While I don't agree with your 'do it the way the svn UI does _because it is an svn tree_' logic (that logic devalues the entire point of bzr-svn operating on svn trees at all), this doesn't mean we can't correct it by changing bzr's UI. > > 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). a .svn directory can operate as a bzr tree, which enables the bzr switch, commit, merge, push, remove, add, status, diff etc commands. Thats orthogonal though; the key issue here is that bzr-svn is doing network traffic to answer an existence query, which is wrong. I'm going to file a separate bug for this. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>. > -- 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
