Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SMGL as GNU-certified Free(R)(TM) Distro?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] SMGL as GNU-certified Free(R)(TM) Distro?
  • Date: Thu, 3 Nov 2005 09:52:11 -0800

On Thu, Nov 03, 2005 at 11:51:22AM -0500, Sergey A. Lipnevich wrote:
> Andrew wrote:
> > Nearly every other "distributed" scm (mercurial, cogito, fastcst,
> > bazaar-ng, darcs, etc.) all use the notion of "repository == branch ==
> > working-tree". That model doesnt work for us *at all*, it works for really
> >
> Could you explain it in more details? Perforce model works for us now,
> and that's as "repository=branch=working copy" as it can get. We did OK
> for a few years with it.

Actually perforce is about as far from that as you can get.

In perforce there is a central server (the repository), it stores all
the revision data. You check out files into your working tree (a p4
client). You can check out the same set of files as many times as you want.
This is the same model subversion uses.

In the repository == branch == working-tree paradigm, the repository data
is *in* the working tree, there is no external data store. There is no
"server", everything is in one directory and theres a 1-1 mapping between
branches and working trees (thats good and bad).

As an example in darcs you take a directory tree and initialize it
and add all the files to the repository. Theres a new directory called
_darcs at the foot of the working tree. As you work on files and commit
them, the revision data is added to some sort of structure in that _darcs
sub-directory.

Bazaar-ng, mercurial, cogito, etc. all use slight variations of that,
basically the directory is named differently and the revision storage may
be different but the architecture is the same. They each have varying
degrees of support for "pushing", "pulling", and "merging" from other
repositories. Thats about all that makes them different.

To branch in one of those systems, you copy the working tree elsewhere
and voila! new branch. Remote branching in bazaar-ng is called rsync.
The revision control system doesn't really know anything happened, again,
thats good and bad.


> > small projects, and for huge projects like the linux kernel where branches
> > have official maintainers whose job is mostly to pull in patches from
> > each other. We dont do that here. The in-between solution is a pqm
> > (patch-queue-manager, gets patches via email and applies them), which
> > is quite clunky IMO.
> >
> >
> In CVS and Subversion, you can create a branch just by copying a working
> tree elsewhere, with CVS or .svn directories. It's not declarative
> enough, and you do have to shuttle patches between them if they are
> related, but it works.

We do the same thing in perforce, you branch to somewhere else in the
same repository. Perforce has real declared branches as well, but we
dont use them.

> As for patches in the list (or in Bugzilla), I've
> seen negligible amount of those over the years. Mostly we get defect
> reports, feature requests, or requests to upgrade, but we seldom get
> patches. Hence there's no need to manage them. Why would this need
> materialize suddenly now?

I think we're misunderstanding each other here. Im not saying we should
use a pqm, im just saying what other projects have done when they decide
to use certain distributed scms.

The pqm's job (originally) is for known/trusted developers, not random patch
submissions from bugzilla, to have a way to commit without someone pulling
changes in by hand. Many scms lack "push" support entirely or dont have
any access control. A pqm is a hack to fix those problems. Again I was merely
pointing out that this is what medium sized projects have
done, I dont think its a good solution for us but thats sadly the best many
repository==branch==working-tree scms have to offer at the moment for
automated centralized commits.

-Andrew




Archive powered by MHonArc 2.6.24.

Top of Page