'bzr add' silently refuses to add nested/child trees

Here is the relevant part from .bzr.log for reference:

Tue 2009-04-28 22:53:29 -0300
0.284 bzr arguments: [u'add']
0.375 looking for plugins in /home/cody-somerville/.bazaar/plugins
0.376 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.979 encoding stdout as sys.stdout encoding 'UTF-8'
1.341 opening working tree '/home/cody-somerville/Projects/canonical/lexbuilders/project-config'
1.424 skip control directory '.bzr'
1.605 '/home/cody-somerville/Projects/canonical/lexbuilders/project-config/jauntyunr' is a nested bzr tree
1.686 return code 0

And when I specified the name of the subdirectory to bzr:

Tue 2009-04-28 22:53:38 -0300
0.096 bzr arguments: [u'add', u'jauntyunr/']
0.162 looking for plugins in /home/cody-somerville/.bazaar/plugins
0.162 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.409 encoding stdout as sys.stdout encoding 'UTF-8'
0.616 opening working tree '/home/cody-somerville/Projects/canonical/lexbuilders/project-config/jauntyunr'
0.661 skip control directory '.bzr'
0.716 return code 0

In the second case, it appears bzr is actually working *in* the nested tree.

I don't think its as simple as 'list the things ignored'. We have in the past reported them, and that itself provokes bug reports.

Perhaps we could do something in add -v.

This seems to be the same issue as in
https://bugs.launchpad.net/bzr/+bug/187342

If I run

bzr ignore dir/.bzr

And then run

bzr add dir

Why shouldn't bzr go ahead and add dir's working set, ignoring the nested repo?

On 18 April 2011 09:24, Adam Porter <email address hidden> wrote:
> If I run
>
> bzr ignore dir/.bzr
>
> And then run
>
> bzr add dir
>
> Why shouldn't bzr go ahead and add dir's working set, ignoring the
> nested repo?

Interesting idea. I think I would like a "yes I'm really sure" option
beyond just ignoring the bzrdir, but there is no technical reason it
couldn't work. Each of the trees would see the changes made by the
other as if they were made by the user.

Adam Porter пишет:
> If I run
>
> bzr ignore dir/.bzr
>
> And then run
>
> bzr add dir
>
> Why shouldn't bzr go ahead and add dir's working set, ignoring the
> nested repo?

Maybe because bzr sees the real branch in the dir/ and therefore
prevents you to shoot in the foot?

.bzr directory is ignored by default, IIUC. Why do you want to ignore
it explicitly?

Because I want it to add dir/ to a different repo.

Here's my situation--I realize it's sort of an edge-case:

I have a repository on my laptop storing home-directory dotfiles, like
.bashrc, etc. I symlink those files in the working set to ~/.

I also push the repository to a remote server so that when I SSH to
that server, I'll have the same Bash environment. I push it to
remote:~/homedir, and symlink the files to remote:~/.

On that remote server, I have a separate repository for basically
everything in the remote user's homedir. Since I have to install some
packages locally to that user, it's good to have them stored in bzr in
case something goes wrong (like when I accidentally pushed my laptop's
~/.bin to remote:~/bin, overwriting the remote user's ~/bin, which
contained files from locally-installed packages--though bzr saved me
by moving ~/bin to ~/bin.moved first).

It's not that big a deal, but it would be nice to be able to include
remote:~/homedir in the remote:~/.bzr repo, so that repo could store
everything for that user account.

Basically, I don' t care if a directory has its own .bzr directory--if
I explicitly ignore dir/.bzr, I want another .bzr repo to be able to
store dir/**. I'm not asking it to store dir/.bzr inside another bzr
repo, just what happens to be the working set.

Besides, what if some of the files inside dir/ are ignored in
dir/.bzrignore? For example, I might want to keep a file in dir/
that's only for that remote system, not for my laptop. So I'd want it
in dir/../.bzr, but not in dir/.bzr, which is the one pushed from my
laptop.

I think it boils down to this: bzr should do what I tell it to do. :)
 It's good for it to prevent me from shooting myself in the foot, but
as long as it's not adding dir/.bzr to the repo stored in dir/../.bzr,
why should it care? I think it's being overprotective. It seems
logical that adding dir/.bzr to dir/../.bzrignore should allow dir/**
to be added to dir/../.bzr, but that fails, without even an
explanation. At least, I think there should be a bzr add --force
option.

Again, I realize it's rather an edge case, but I see that I'm not the
only person that's run into this problem, and I don't see why bzr
should refuse to let me do it.

On Mon, Apr 18, 2011 at 00:58, Alexander Belchenko <email address hidden> wrote:
> Adam Porter пишет:
>> If I run
>>
>> bzr ignore dir/.bzr
>>
>> And then run
>>
>> bzr add dir
>>
>> Why shouldn't bzr go ahead and add dir's working set, ignoring the
>> nested repo?
>
> Maybe because bzr sees the real branch in the dir/ and therefore
> prevents you to shoot in the foot?
>
> .bzr directory is ignored by default, IIUC. Why do you want to ignore
> it explicitly?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/368988
>
> Title:
>  'bzr add' silently refuses to add nested/child trees
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/bzr/+bug/368988/+subscribe
>

Adam Porter пишет:
> Because I want it to add dir/ to a different repo.

Then remove .bzr directory from it and you're done.

> Here's my situation--I realize it's sort of an edge-case:

I can honestly say that I don't understand your situation because it's
too much complicated for me, sorry. But I'm not core developer of bzr,
so my words reflect only my opinion.

> I think it boils down to this: bzr should do what I tell it to do. :)

Unless this is contradict to the way bzr works.

> Again, I realize it's rather an edge case, but I see that I'm not the
> only person that's run into this problem, and I don't see why bzr
> should refuse to let me do it.

I should add contra-argument: the current behavior is used currently in
two plugins: bzr-externals and scmproj which tries to emulate
sort-of-netsed-trees. If you really want nested trees then ask for them.
But asking to change the bzr to ignore the nested branches and be able
to add their content to top-level branch is contradict to the bzr model
in my opinion. And I personally as long term user don't want to break
this behavior.

--
All the dude wanted was his rug back