Re: [Gnu-arch-users] Looking for references ( Was: [arch-users] diagnosing svn)

[Tom Lord]

    > From: "Thaddeus L. Olczyk" <address@hidden>

    > Sorry to repost. But since it's been about two days, I thought
    > the original post may be to old and people may have missed
    > my question because they never saw it. 

    > On Thu, 20 Feb 2003 14:20:19 -0800 (PST),
    > address@hidden (Tom Lord) wrote:
    > 
    > >uppose you have the same intuition that Walter expressed a while
    > >   back, which I'll paraphrase as:  "The first and most fundamental
    > >   task of a revision control system is to take snapshots of working
    > >   directories." 
    > >
    > >   If you don't believe that that's a seductive (even though wrong)
    > >   intuition, go back and look at how I replied.  It took many, quite
    > >   abstract paragraphs. 
    > Ok. I've spent a while looking for this exchange with no success.
    > Can you point me to it?
    > Thaddeus L. Olczyk


It appears to be from January -- just over a month prior to what you 
are looking at.   The specific paragraphs referred to are included.


-t


------- Start of forwarded message -------
[The indented materials are things I was replying to -t
 I've also learned since then how to spell "intentional".]

Date: Sun, 12 Jan 2003 16:35:17 -0800 (PST)
From: Tom Lord <address@hidden>
To: address@hidden
In-reply-to: <address@hidden> (message from Walter
        Landry on Sun, 12 Jan 2003 14:54:11 -0800 (PST))
Subject: Re: address@hidden: Re: [arch-users] separate commands prevent
 errors]



            The most important feature of a _revision_ control system
            is to be able to get back old _revisions_.

Um..no.  Perhaps that's where SCCS started out, many years ago.

"Revision" is a little bit ambiguous.  It could mean the full text of
a project tree associated with some revision name; or it could mean
the changeset associated with some revision name.  On this list we've
been using it in the former sense -- I assume that you are too -- but
in some ways, the latter sense gives a better idea of what a
"_revision_ control system" is for.

Revision control these days is about much, much more than just
snapshotting trees.  It's about coordinating a set of developers whose
work is scattered in space and time.  It's about managing the workflow
of programmers by providing control over the processes by which their
revisions (the changes they make) are combined and propogated.  It's
about giving programmers the technology to express changes _as_
changes which then have meaning when applied to more than just one
tree or when browsed directly.

Hardlink trees can snapshot trees.  Modern filesystems can snapshot
trees in fancier ways.  Disks are big enough so that for many
projects, `tar zcvf' is all you need to snapshot trees.  Snapshotting
trees is not what makes a system a revision control system.

        Arch uses changesets as an optimization, 

It does.  But it also makes changesets first-class objects which
programmers create and manage explicitly, because changesets are in
and of themselves useful and important to project management.  arch
distinguishes between "intensional changesets", those that a
programmer decides to label as "The changes that accomplish such and
such", from "computed changesets", those that reflect a whole-tree
diff between two arbitrary trees.   Intensional changesets are
assigned names and log messages -- they're cataloged.   Computed
changesets are constructed as needed, using the coordinate system
provided by intensional changesets to express what computed changeset
is desired.

When you use intensional changesets, you can have some expectations
that don't, in general, apply to computed changesets.  For example,
you can expect them to be organized largely as lines-of-development
and, so organized, smarter approaches to merging are available.

I have some boilerplate:

>                     WHAT IS REVISION CONTROL?
>
>   It is the role of revision control systems to provide two broad
>   classes of functionality:
>
>       A) The cataloging and archival of unitary changes made
>          (primarily) to software and documentation source code,
>          deliberately and explicitly, by contributors to that code.
>
>       B) The quasi-algebraic manipulation of unitary changes to form 
>          useful combinations of changes;  the combination and
>          coordination of work made by single or multiple
>          contributors acting across space and time.
>

The functionality "get back old [tree states]" is a subset of (A) and
(B).

- -t
------- End of forwarded message -------