Re: [tlug] Linux Format magazine

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Josh" == Josh Glover <jmglov@example.com> writes:

    Josh> ...oh, I just got it. The final doc does *not* go back into
    Josh> our SVN repository, since it is just fodder for Linux
    Josh> Format. Linux Format's final PDF proof *should* go into our
    Josh> repository (since, presumably, we want it on our website--LF
    Josh> copyright permitting, of course).

Actually, I had "nuke the svn repo" in mind. ;-)  I don't want to get
into scm wars here, but basically for this kind of task a centralized
scm is a bad idea for several reasons, specifically

1.  most of the branches are garbage and/or temporary
2.  this is the kind of thing you can hack on offline
3.  there's no reason to inhibit people sharing "behind the official
    repo's back"

and the killer

4.  we don't want the official repo online, at least not writable

    Josh> So for a workflow like this, the correct steps should
    Josh> probably be:

You don't understand distributed SCM, I think.  :-)  There are several
kinds of objects here that we need to work with.

1.  Source tree
2.  Branch metadata
3.  Workspace
4.  Repo

The source tree is the stuff we work on, here the abstract.  A branch
is the metadata that allows us to reconstruct one or more related
source trees from repo data.  A workspace is a combination of a branch
with a source tree.  And a repo contains the metadata for one or more
branches plus the data to reconstruct all corresponding source trees.

Now, in a centralized SCM like CVS or Subversion, a repo contains an
entire project tree (ie, all of the branches).  Then in a workspace
the branch identifier is just the tip (ie, in CVS the collection of
versions in the CVS/Entries files, AIUI in svn a single commit
number).  Given that identifier the server can reconstruct the source
tree and send it to the client.

In distributed SCM, every branch is a repo is a workspace[1], but there
is no requirement that any repo contain all the branches.  This means
that metadata becomes more complicated, because you may not have full
version history.  Another way to look at this is that in CVS or
Subversion, in cvs update -r tag the server mostly sends patches, but
this is a pure optimization---the server knows what the content of
each file is, and can send it.  In Arch, darcs, or git, however, you
must communicate by patches because the source repo is not necessarily
able to construct a given version without the help of the target
repo/workspace.

So the workflow would look more like this:

1.  Create a publicly read-only repo.
2.  Interested parties including the document-owner clone the
    semi-public repo into personal repos.
3.  Interested parties exchange patches in the usual ways for the scm,
    security mechanisms determined by each repo owner.
4.  Document-owner pushes any versions deemed of general interest to
    r/o repo.

Admittedly, there is a pretty big issue hidden in "the usual ways" in
3.  Namely, repo discovery and inter-repo handshaking.  None of the
distributed scms have "solved" this problem, although Arch has gone
pretty far.  On the other hand, it turns out that most folks have
little trouble announcing and establishing links among repos.  All of
them support HTTP URLs for r/o access, which is all you need if
everybody pulls patches from everybody else.  This generally works
fine for this kind of application.

    Josh> Of course, a Wiki might be the way to go for workflows like
    Josh> this. Is there Wiki software available that can track the
    Josh> complete revision history of a document?

I'm pretty sure most wikis allow this, but in many cases (eg,
Zope-based wikis like ZWiki) the database is pretty space-inefficient.

    Josh> Didn't we discuss a Wiki awhile back? Was there interest in
    Josh> having a TLUG Wiki? I am pretty sure I could convince Mauro
    Josh> to let me set one up on tlug.sauco.net as a beta so we could
    Josh> gauge how useful such a resource would be to TLUG. Should I
    Josh> do it?

It's probably a good idea, wikis are very convenient especially for
this kind of thing.  But the wiki should be hosted on hikari and
generally available to be of most use.  I don't know if we want to do
that.


Footnotes: 
[1]  Strictly speaking, branches and repos need not contain any
checked out source trees, but that makes no sense for a workspace.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.