bzr add target repository specification

Aaron Bentley aaron at aaronbentley.com
Fri Feb 25 01:02:49 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-02-24 05:49 PM, W. Trevor King wrote:
> On Thu, Feb 24, 2011 at 05:23:00PM -0500, W. Trevor King wrote:
>> On Thu, Feb 24, 2011 at 04:17:29PM -0600, John Arbash Meinel wrote:
>>> The only reason it wasn't working for 'cmd_add' was because you were
>>> specifying the location 2 times. One as a read source, and one as a
>>> write source.
>>
>> Ah, so it's:
>>
>>   1) I'm adding files from an explicit (external) repository (at
>>      `file_ids_from`), let's get a read lock there.
>>   2) I'm adding files to the current repository ('.'), let's get a
>>      write lock there. *crash*
>>
>> If so, that's troublesome.  My intention in using `file_ids_from` was
>> to set the donor repository, not the acceptor.  I suppose that the
>> acceptor is assumed from the current working directory?  How would you
>> add a new file stored in repository B's directory while working from
>> repository A's directory?  Or do you need to explicitly change
>> directories before the call?

To add a new file stored in tree B, you specify path to the file.  We
add it to the tree that most directly contains the file.  That is, we
walk up the parent directories one-by-one until we find a tree, and then
we add it to that tree.

> Obviously for this to work, B would have to be nested inside A.  As an
> explicit example:
> 
>     tmp $ mkdir a
>     tmp $ cd a
>     a $ bzr init
>     Created a standalone tree (format: 2a)                                         
>     a $ mkdir b
>     a $ cd b
>     b $ bzr init
>     Created a standalone tree (format: 2a)                                         
>     b $ touch c
>     b $ cd ..
>     a $ bzr add b/c
>     adding c
>     a $ bzr status
>     unknown:
>       b/
>     a $ cd b
>     b $ bzr status
>     added:
>       c
> 
> When I was trying to add the file `b/c` to the repository at `a`.  Is
> there a way to do this?

There is no way I'm aware of to do this.  I suppose there may be bugs
that permit it in some cases, but it's not behaviour we intended to
support.  We think that if a file in a working tree is versioned, it
should be versioned by the working tree that most directly contains it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1m/7kACgkQ0F+nu1YWqI3FigCbBAUS4mBbMk0BSUzH25OyyjW5
ACwAn1w8I1kA5kBr5/mVtVLKab0ghsjM
=r1BJ
-----END PGP SIGNATURE-----



More information about the bazaar mailing list