Questions about distributed repositories
nick at byu.edu
Fri Mar 11 08:23:08 MST 2005
On Thursday 10 March 2005 09:16 pm, Richard Esplin wrote:
> Suppose that I check out a copy of the master repository on my local
> machine and make 10 commits to it. These commits do not effect the code in
> the master repository. I can commit a log message with each local check-in,
> and I can roll back my local copy to any of those ten versions any time I
> want. At some point I can merge my local repository with the main code base
> so that other developers on my team can use it. When other developers on my
> team sync with the main repository, they will then have my changes. This
> much I understand.
> My question will make more sense if I define some variables:
> The master repository is M
> The initial state of the master repository is M[A]
> My local repository is L
> Initially the state of my local repository is L[A]
> Initially M[A]=L[A]
> I do various changes to make L[B], L[C], . . . L[K]
> I merge L[K] with M[A] to get M[L]=L[L].
> My understanding is that at this point, I can roll L back to any revision
> L[B] . . .L[L]. But, as I understand it, I can only roll M back to M[A]. M
> has no understand of revisions [B] through [K]. Is that correct?
This may depend on the system you choose. I only have experience with CVS and
<flame suit on>
Bitkeeper has really good, gui tools that make it visually apparent what's
happening with the repositories and changesets--it's really hard to get
confused. You may try it out just to get a better idea of what some of these
distributed systems are doing.
</flame suit off>
With Bitkeeper, at least, when you sync L back to M, you are actually
'pushing' all of your changes between L[A] and L[K] to M. So M now has full
knowledge of all of the changesets L[B]-L[K]. When some other developer
'pulls' from M to incorporate your changes into his local repository D, he
actually gets L[B] - L[K] which are merged in.
> If another developer syncs with M[L] to create D[L], can the developer roll
> D back to any previous revision?
> With CVS, I would occasionally look at a file in the repository to browse
> all log messages and all changes ever made to a file. Knowing the complete
> history of a file can really help to fix bugs, especially with regards to
> business logic. Is this possible with a distributed repository system? Does
> M, or anything synced with M after revision [L] (such as D), know about the
> log messages and changesets stored in L during revisions [B] through [L]?
> Can M or D revert to revision [B] through [K]? What happens to local log
> files after a branch merge?
Yes. Yes. With Bitkeeper, the changesets are self-contained. The changeset
as a whole has metadata such as author, time, and an overall description of
the change. Additionally, each individual file affected in the changeset can
have it's own unique comments. All of this is distributed together.
> The thing that most draws me to a distributed repository system is the
> ability to commit often with more fine-grained log messages without
> breaking the main repository; I see this as being a great tool for
> documenting the logic of the software. If those fine-grained log messages
> and changesets are lost when I merge with the main repository, then much of
> the usefulness of a distributed repository system would be lost. Can it be
> used in the way I am thinking?
I've been trying to convince my company to take a closer look at Bitkeeper. I
learned it when working with MySQL--it's what they use. I was thoroughly
impressed with the robustness while easy-to-use was also retained. The tools
are for the most part very intuitive. (there are both gui and cli tools for
I haven't looked closely at the open source alternatives. I did look into
arch a while back and was heavily disappointed at the confusing cli-only
tools. This, of course, only comparing to my experience with Bitkeeper.
Sales Team Automation, LLC
1335 West 1650 North, Suite C
Springville, UT 84663 +1 801.853.4090
More information about the PLUG