bzr-svn is irritating when in a (non-svn) subdirectory of an svn working tree

[Colin Watson]

Binary package hint: bzr-svn

I keep parts of my home directory (mainly dotfiles) in Subversion. As a result, I am nearly always in a subdirectory of a Subversion checkout, although my current working directory usually does not have a .svn directory. bzr-svn exhibits irritating behaviour in this case, such as:

  <cjwatson@sarantium ~/src/debian/telegnome/bzr/telegnome>$ bzr init
  bzr: ERROR: Connection closed: Connection closed unexpectedly

Note that ~/src/debian/telegnome/bzr/telegnome/ does not have a .svn subdirectory, nor do any of its parents until you get right the way back to ~ itself. I don't think it's reasonable for bzr-svn to try to contact the Subversion repository in this case (I happened to have just disconnected from my wired network, so the failure was visible). Is there any reason for bzr-svn to do anything if the directory being operated on doesn't itself have a .svn control directory? Subversion, of course, keeps a .svn directory in every subdirectory rather than just at the top of the tree like Bazaar, so it's easy to tell when you're in a non-versioned subdirectory.

[Robert Collins (lifeless)]

here is what happens:
bzr looks upwards directory by directory
at each directory all control directory types are given a chance to report 'owned' or 'not owned'. bzr-svn has no information given to it to let it decide that the svn directory is not relevant (and presumably also trigger an end to the search). We'll need to think about a good way to manage this to address it

[Robert Collins (lifeless)]

further to that it may be the wrong thing to 'fix' it anyway, because to preserve the behaviour of 'bzr add' working in a subdir, in a svn tree, it /should/ find containing svn control directories and use the one found to add paths.

[Robert Collins (lifeless)]

A workaround is to do
bzr init
rm .bzr/{checkout,branch,repository}

in a directory above where you use bzr; this will cause the search for a branch-or-tree to abort at that path.

[Jelmer Vernooij (jelmer)]

marking this as invalid for bzr-svn since the logic that triggers this bug is in bzr.

[Colin Watson (cjwatson)]

Robert Collins wrote:
> further to that it may be the wrong thing to 'fix' it anyway, because to preserve the behaviour of 'bzr add' working in a subdir, in a svn tree, it /should/ find containing svn control directories and use the one found to add paths.

No, I don't think that's correct. If the current directory has a .svn control directory, then it should indeed use that. However, I repeat, every versioned subdirectory of a Subversion working copy has a .svn control directory, not just the root of the tree as in Bazaar. A subdirectory of a Subversion working copy that does not itself have a .svn control directory is simply not part of that working copy as far as Subversion is concerned. 'svn add' fails in such a circumstance:

  svn: '.' is not a working copy
  svn: Can't open file '.svn/entries': No such file or directory

Therefore, 'bzr add' shouldn't try to treat this environment as part of a Subversion working copy either.

Thanks for the workaround. I've just removed bzr-svn for the meantime, as I don't use it very often and can just install it when I need it.

[John A Meinel (jameinel)]

I don't think it is strictly invalid for bzr-svn, as we need to come up with a way for the two to co-exist. bzr core probably needs to provide a way for bzr-svn to know what is going on, and then bzr-svn needs to use it.

Specifically, "BzrDir/Branch/WorkingTree.open_containing" should probably be signaling that it is looking for the container of file/dir X. Then bzr-svn can always say "if dirname(X) != base_dir: raise NoBranch"

The current layering doesn't really allow it, since we just probe_transport at each level.

[Jelmer Vernooij (jelmer)]

In this particular case bzr is looking for a shared repository it can use. bzr-svn's local BzrDir subclass only implements BzrDir.find_repository(). Its BzrDir.open_repository() implementation always returns NoRepositoryPresent.

Why is bzr in this case calling find_repository() if it's checking a specific location rather than open_repository(), which would make more sense to me?

[Robert Collins (lifeless)]

On Mon, 2008-02-18 at 20:33 +0000, Colin Watson wrote:
> Robert Collins wrote:
> > further to that it may be the wrong thing to 'fix' it anyway, because to preserve the behaviour of 'bzr add' working in a subdir, in a svn tree, it /should/ find containing svn control directories and use the one found to add paths.
>
> No, I don't think that's correct. If the current directory has a .svn
> control directory, then it should indeed use that. However, I repeat,
> every versioned subdirectory of a Subversion working copy has a .svn
> control directory, not just the root of the tree as in Bazaar. A
> subdirectory of a Subversion working copy that does not itself have a
> .svn control directory is simply not part of that working copy as far as
> Subversion is concerned. 'svn add' fails in such a circumstance:
>
> svn: '.' is not a working copy
> svn: Can't open file '.svn/entries': No such file or directory

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. Running
'bzr add' in an unversioned directory of a tree bzr is able to modify,
will add that directory, and its parents, until it encounters the
closest versioned directory.

> Therefore, 'bzr add' shouldn't try to treat this environment as part of
> a Subversion working copy either.

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.

> Thanks for the workaround. I've just removed bzr-svn for the meantime,
> as I don't use it very often and can just install it when I need it.

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. 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).

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>

[John A Meinel (jameinel)]

Well, the fact that "bzr init" is failing is a bit odd. I guess it is searching for a containing repository, and bzr-svn tries to connect to the upstream svn repo and then dies with an exception rather than just returning that this cannot be a shared repository.

Or is "bzr init" underneath a .svn directory supposed to create a new svn branch?

[Robert Collins (lifeless)]

On Mon, 2008-02-18 at 22:17 +0000, John A Meinel wrote:
> Well, the fact that "bzr init" is failing is a bit odd. I guess it is
> searching for a containing repository, and bzr-svn tries to connect to
> the upstream svn repo and then dies with an exception rather than just
> returning that this cannot be a shared repository.
>
> Or is "bzr init" underneath a .svn directory supposed to create a new
> svn branch?

bzr init under a .svn containing directory should create a bzr
standalone repository. Going back to the original bug, bzr-svn's
erroring here seems to be a problem.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Jelmer Vernooij (jelmer)]

See my post earlier - bzr seems to be using find_repository() here while open_repository() is more appropriate.

I don't think calling find_repository() on a BzrDir implementation should raise NotBranchError if there is clearly something else going wrong.

[Robert Collins (lifeless)]

On Mon, 2008-02-18 at 22:55 +0000, Jelmer Vernooij wrote:
> See my post earlier - bzr seems to be using find_repository() here while
> open_repository() is more appropriate.
>
> I don't think calling find_repository() on a BzrDir implementation
> should raise NotBranchError if there is clearly something else going
> wrong.

init needs to use a shared repository if one can be found; so
find_repository is the right api.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>

[Colin Watson (cjwatson)]

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...

[Robert Collins (lifeless)]

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...

[Colin Watson (cjwatson)]

On Wed, Feb 20, 2008 at 09:24:53PM -0000, Robert Collins wrote:
> For an unversioned, unignored subtree of a working tree

I would just like to note that the subtree in question in fact happens
to be ignored.

Thanks,

--
Colin Watson [<email address hidden>]

[Robert Collins (lifeless)]

On Thu, 2008-02-21 at 14:02 +0000, Colin Watson wrote:
> On Wed, Feb 20, 2008 at 09:24:53PM -0000, Robert Collins wrote:
> > For an unversioned, unignored subtree of a working tree
>
> I would just like to note that the subtree in question in fact happens
> to be ignored.

Ha! cool. I think you'll find the next version of bzr-svn much less
irrirating, Jelmer has fixed the key bug causing bzr to behave un-bzr'ly
in this case. Certainly bzr init will no longer ask for an svn
password :)

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>

[Colin Watson (cjwatson)]

Thanks! Glad to hear it.