Questions about distributed repositories
eric at emstraffic.com
Fri Mar 11 09:27:49 MST 2005
I've tried setting up our web development environment with CVS, Archs,
and Darcs and so far I am loving Darcs. Like Hans mentioned, it is
patched based and each patch consists of mini-patches of each change you
made in every file. You can add entries for each of these changes, but
you can choose to add or ignore each one before creater the main patch.
Key is to just `record` often so you patches are well broken up. Once
you push a patch you can unpatch any of them as long as they are not
dependant upon each other. You can also tag your repository with a
version number and roll back to any revision number you would like.
With Darcs each developer has their own checkout of the test/dev server
code base. Work on your projects, make your patches, etc. Then
everybody pushes them to the test server where we check for conflicts
and stability with the merged code. Once a feature is good, we push
just the patches we need for that, leaving the ones still in
development, to the live server. We can then send hotfix patches
straight to the live server if anything comes up, unpatch one or more of
the patches, or roll back to a previous version/tag.
So far I am really digging Darcs, this patching idea just really appeals
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.
>| This has been a P.L.U.G. mailing. |
>| Don't Fear the Penguin. |
>| IRC: #utah at irc.freenode.net |
More information about the PLUG