Questions about distributed repositories
hans at fugal.net
Fri Mar 11 08:34:30 MST 2005
With darcs, at least, you send or pull each patch individually. (with
the option of course to do things en masse) So the full history will be
there, just as you are hoping.
On Thu, 10 Mar 2005 at 21:16 -0700, Richard Esplin wrote:
> Warning: long email follows.
> I am tired of the limitations of CVS, and I want to switch to a distributed
> version control systems. The recent thread on this list was very informative,
> but left me with some questions about which I hoped the plug could enlighten
> me. Up until now, I have only used CVS extensively, so that is my basis of
> comparison. My current short list of VCSes is darcs, Tom Lord's arch, and
> Aegis. Specific responses dealing with these systems would be appreciated.
> First, has anyone looked at Aegis? It is a filesystem centric VCS that has
> been around over ten years. It sounds very feature complete and mature. Why
> doesn't it get the buzz that arch and darcs draw?
> My next questions have to do with flaws in my understanding of distributed
> repositories. Please help clarify my thinking:
> I understand that a distributed revision control system does not enforce the
> concept of a master repository, but that it may be convenient for a
> development team to have a single place to sync all revisions. Let's call
> this place the master repository. It only differs from developer repositories
> because that is where the production branch is stored.
> 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?
> 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?
> 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 appreciate any explanations.
> Richard Esplin
> | This has been a P.L.U.G. mailing. |
> | Don't Fear the Penguin. |
> | IRC: #utah at irc.freenode.net |
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050311/f78e3fa9/attachment.bin
More information about the PLUG