Equivalent to svn tags?

Aaron Bentley aaron.bentley at utoronto.ca
Thu Oct 25 14:05:16 BST 2007


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

Matthew D. Fuller wrote:
> On Thu, Oct 25, 2007 at 08:06:21AM -0400 I heard the voice of
> Aaron Bentley, and lo! it spake thus:
>> Have you seen bzrtools' multi-pull?
> 

> - It's a pull, not a branch, so I still have to individually branch
>   all the branches.

Well, you did say the problem was with "pull", not "branch".

> - It pulls "all branches at this location in my fs", not "all branches
>   in this logical set", which can have other side effects.

To me, it's always seemed unlikely you'd really want the whole set in a
repository.  If the repo holds several subprojects, then I can imagine
wanting one copy of each.  But I don't know why anyone would want a full
mirror of bzr-v

>   For
>   instance, I may have my own branches around there, that have one of
>   the upstream branches as parents, and I may end up pulling over a
>   currently-fully-merged branch where I didn't want that mainline
>   trashed.

Is this a situation where the append_only flag helps?

I actually think that merge should have a different default location
than pull.  I have many branches that I merge and pull into (e.g.
bzr.ab).  The merge location is never the same as the pull location, but
I perform both operations fairly frequently.

> - It treats it all branch-at-a-time still.  Doing a no-op pull can
>   easily take several seconds just to find that out.  In a
>   multi-branch setup, they'd all be coming from the same place, so all
>   of them could be checked at once, and 5 seconds later I'd see
>   "nothing to do".  If it takes 5 seconds to find out there's nothing
>   to do for each branch, though, and I have 15-20 sitting there...  it
>   takes minutes just to do nothing (this is another SS topic
>   intersection).

Yes, the smart server could aggregate branch up-to-date checks without
changes to the physical format.  Branch listing, too.

> There are real obstacles to getting good fit solutions to all (or even
> all the major) problems.  But I don't think they're all technical, or
> inherent in the positions we've staked out bzr to hold.  The biggest
> obstacle is not "we can't do that and have bzr remain bzr", it's
> cycles; it's "we can put that on our todo list right after the higher
> priority stuff; how's 2015 for ya?"

It's also: what solution can we find that would be a good answer to a
lot of problems?  We don't want to have a million different solutions,
because that's confusing, and also brittle.  Some people would say
programmers can't even differentiate between "pull" and "update":

http://blog.red-bean.com/sussman/?p=79

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

iD8DBQFHIJSM0F+nu1YWqI0RArhCAJ4v5zxFJHNwTjxAs+1no/hnkFkHrwCcCeTC
cXM4y/tRd4R0yks1IrpJCFE=
=iEck
-----END PGP SIGNATURE-----



More information about the bazaar mailing list