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