Two little things (Mainly win32 related)

John A Meinel john at
Tue Jun 7 23:01:30 BST 2005

Roncaglia Julien wrote:
> Roncaglia Julien said the following :
>>First a small path attached who do a simple glob replacing in win32
>>(*.py or *.cpp *.h are easier than adding everything by hand)
> Also note that what is missing in this path is that ignored files are
> added if they match, i think this is also the case when the expanding is
> done by some unix shell but seem counter-intuitive.

As mentioned in my other email, these will be ignored if you add the
directory, rather than adding individual files.

As abentley mentioned, in Unix the glob occurs *before* the program
receives it's arguments, (it is done by the shell). On windows, the
shell doesn't expand wildcards, and so must be done by the user.

I would say *don't* ignore glob expansions, since it changes the
semantics of "bzr add *.py".

Remember, if you accidentally add something you didn't want to, you can
always "bzr remove", which should do what you want. (And if
you haven't committed yet, there is effectively no change.)

> ***
> And i have a question related to id : Why did the Working tree
> considered by "add" is the one where reside the first file in the list
> and not the one in the current directory ????
> F:\some_project> bzr add "F:\some_bzr_managed_directory\"
> Will try to add the two files to F:\some_bzr_managed_directory\ and not
> F:\some_project\ it seem a little strange to me (And it also create an
> annoying egg-chicken problem for ignoring ignored files when applying
> glob expanding)

Well, first off, you can't add a file that is not in the working tree
(in a subdir of the directory with .bzr/). So:

F:\some_project> bzr add "F:\some_other_project\"
Will always try to add the file to some_other_project. Especially since
it *cannot* exist in F:\some_project.

Since is in the current directory, it should obviously be
added to F:\some_project. However, I don't know that we really want "bzr
add" to be able to add files to more than one project at a time.

I suppose we could, but that would mean detecting when a new file won't
fit into the old path. Maybe it is just as simple as for-each file, find
the tree-root, and add it. Probably isn't a whole lot of overhead to do
this for each file.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : 

More information about the bazaar mailing list