On Sat, Oct 21, 2006 at 04:05:18PM -0400, Aaron Bentley wrote:
> Carl Worth wrote:
> > On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:
> [...]
> > But it really is fundamental and unavoidable that sequential numbers
> > don't work as names in a distributed version control system.
>
> Right. You need something guaranteed to be unique. It's the revno +
> url combo that is unique. That may not be permanent, but anyone can
> create one of those names, so it is decentralized.
But it is *not* *distributed*. The definition of a distributed system
among other things require, that resource identifiers are independent on
the location of the resources. So only using the revision-ids is really
distributed.
> >> I meant that the active branch and a mirror of the abandoned branch
> >> could be stored in the same repository, for ease of access.
> >
> > Granted, everything can be stored in one repository. But that still
> > doesn't change what I was trying to say with my example. One of the
> > repositories would "win" (the names it published during the fork would
> > still be valid). And the other repository would "lose" (the names it
> > published would be not valid anymore). Right?
>
> No. It would be silly for the losing side to publish a mirror of the
> winning branch at the same location where they had previously published
> their own branch. So the old number + URL combination would remain valid.
I regularly use bzr and I never used git. But I'd not hesitate a second
to pull --overwrite over the old location. Because the url has a meaning
"the base I develop against" for me and I'd want to preserve that
meaning.
> If the losing faction decided to maintain their own branch after the
> merge, they'd have two options
>
> 1. continue to develop against the losing "branch", without updating its
> numbers from the "winning" branch. It would be hard to tell who had won
> or lost in this case.
>
> 2. create a new mirror of the "winning" branch and develop against that.
> I'm not sure what this point of this would be.
>
> I think the most realistic thing in this scenario is that they leave the
> "losing" branch exactly where it was, and develop against the "winning"
> branch.
>
> >> Bazaar encourages you to stick lots and lots of branches in your
> >> repository. They don't even have to be related. For example, my repo
> >> contains branches of bzr, bzrtools, Meld, and BazaarInspect.
> >
> > Git allows this just fine. And lots of branches belonging to a single
> > project is definitely the common usage. It is not common (nor
> > encouraged) for unrelated projects to share a repository, since a git
> > clone will fetch every branch in the repository.
>
> Right. This is a difference between Bazaar and Git that's I'd
> characterize as being "branch-oriented" vs "repository-oriented". We'll
> see more of this below.
This is one of things I on the other hand like better on bzr than git.
Because it is really branches and not repositories that I usually care
about.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@xxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html