M-x big-picture

[Ben Collins-Sussman <su...@newton.collab.net>]

Alpha Checklist (?)

The client-side of things is much further along than the server-side
of things.  Before we start focusing all of our attention on the
filesystem, I wanted a clean list to (later) remind us how to jump
back into the rest of the project.  STACK has turned into a big mess
-- and that's okay, it's a scratch area.  This is something cleaner
for future reference.

Assuming the filesystem is up and running, I believe this is a list of
everything that needs doing before we can start to admit that we're
getting close to a QA'able first "alpha" release of subversion.

 * write general "multiple target" logic in client

    * need shared code which will

       * remove redundant targets from a target list
       * find the longest common ancestor path of a target list

    * need to make all libsvn_client commands utilize this logic

    * updates need to bump revisions on everything, not just changed
      objects.

 * general changes #2, 3, 4, 5, 6, 7 

   Change #2:  Modify prototypes of replace_*() and add_*()
   Change #3:  New "WC" properties.
   Change #4:  Revise the commit cleanup process.  (in svn_ra.h)
   Change #5:  The "report" editor doesn't exist.
   Change #6:  Move textdeltas to the "other side" of the editor.
   Change #7:  New filesystem "copy" nodes implies renaming add_*() args

 * ra_dav -- this is GREG'S BIG PROJECT.  :)

 * ra_local:

      *  --> editor interface which writes to a fs transaction
      *  <-- routines to read the fs and drive update editor

 * make sure the client can handle moves/renames/copies:

      * <-- update editor should gracefully handle "adds with
        history" (the essence of moves/rename/copy).
      * --> `svn mv/cp' should register a `delete' and
        `add-with-history' in the WC entries files.

 * branching and merging commands

 * log history commands

 * annotate commands

 * cvs --> svn repository converter

--------------------

Things that should *probably* be in SVN 1.0, but not necessarily:

 * tracking of changeset-like metadata, so we can do "genetic merging"

 * client-side diff plugins (in command-line client)

 * win32 gui

 * svn --> cvs (lossy) repository converter

--------------------

Remember that for SVN 1.0, we need *compelling* reasons to make
somebody switch to it over CVS.  Right now, assuming SVN does
everything CVS does, those compelling reasons are:

   * much, much faster networking

   * versioning of directories, moves, renames.

These are probably the two largest gripes of CVS users.

Re: M-x big-picture

[Ben Collins-Sussman <su...@newton.collab.net>]

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:

> a) All sorts of copies must be O(1)

That's the plan.

> b) A "svn copy" will do nothing but create a new "copy" node, which 
> contains the copy source's node revision and path.

Right.  

And, if the node that we copied is a directory, then the new "copy"
node *appears* to be a new directory too.  If we never touch this copy
node ever again, we have ourselves the equivalent of a tag.

> c) Subsequent changes to a "copy" node will automagically create "file" 
> or "dir" successors (on the ame branch), according to the type of the 
> copy source.

Sure.

> O.K., that's all clear as long as the source is a file. If it's a 
> directory, we actually want to copy the whole tree. So it seems to me 
> that we have to create copies of its children when they change, but I've 
> seen discussions about creating branches instead.

I think you're right.  If, in my example above, somebody decides to
modify a child beneath the directory `copy' node, we need to start
making new node-revisions underneath.  This *is* a branch.  

The confusion here comes from user-interface land.  When a client user
types `svn tag', what will happen?  A new subdir copy-node will be
created somewhere in the filesystem.  We talked about this behavior
last May, but never came to a full decision about how to best present
this model to the user.  Do we let the user see new subdirs spring to
life, or do we somehow hide this?  Do we structure the repository
filesystem so that all tag/branch subdirs are in one place?  Lots of
open issues here.

Re: M-x big-picture

[Jim Blandy <ji...@zwingli.cygnus.com>]

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> I have a big question mark about this sitting somewhere around my 
> hypothalamus. I suspect I really don't understand our copy-is-branch 
> model, even with the proposed changes to create a "copy" node type in 
> the filesystem. I'm especially muddled about directory copies. I'd like 
> to clear things up. Here's what I think I understand:
> 
> a) All sorts of copies must be O(1)
> 
> b) A "svn copy" will do nothing but create a new "copy" node, which 
> contains the copy source's node revision and path.

Nope.  An "svn copy" does nothing but create a new directory entry
referring to the same node revision as the original.  (In Chicago, we
did discuss the possibility of adding "copy nodes" to get certain
things right, but I want to leave that out of the picture for now, and
get the simpler worldview working.  Things work fine without them.)

When you want to commit a change to the copy, the change creates
successors (in the node revision sense) of each node that is changed,
and to their parent directories, parents' parents, etc. and makes the
changes to the successors.  Eventually this results in a successor to
the root node, which we install as the root of the new revision.

Since the original of the copy refers to the same node revision it
used to, not the successor, the original is unaffected.

Don't assign any significance to node revision numbers, other than the
successor/ancestor relationship.  The only reason we can't just use
simple linear numbering is that we need the ability to create an
arbitrary number of successors to any given node revision, and we want
the node revision numbers to encode that successor/ancestor
relationship.  But there is no sense in which 10.3 is a "more
distinguished" successor to 10.2 than 10.2.1.1.  Neither is
necessarily the branch, nor the trunk.  Whoever needs a successor to
10.2 first gets 10.3; everyone after than gets 10.2.n.1, with
increasing n.

Re: M-x big-picture

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:

> Alpha Checklist (?)
> 
> The client-side of things is much further along than the server-side
> of things.

Yeah, I really didn't have much time lately. Release pressure ... JimB 
also seems to have vanished, too, so not much has been done on the 
filesystem in the last couple of weeks. The list in STACK is more or 
less up to date, though.

I *hope* to put in several hours' work tomorrow night.


>  * branching and merging commands

I have a big question mark about this itting somewhere around my 
hypothalamus. I suspect I really don't understand our copy-is-branch 
model, even with the proposed changes to create a "copy" node type in 
the filesystem. I'm especially muddled about directory copies. I'd like 
to clear things up. Here's what I think I understand:

a) All sorts of copies must be O(1)

b) A "svn copy" will do nothing but create a new "copy" node, which 
contains the copy source's node revision and path.

c) Subsequent changes to a "copy" node will automagically create "file" 
or "dir" successors (on the ame branch), according to the type of the 
copy source.

O.K., that's all clear as long as the source is a file. If it's a 
directory, we actually want to copy the whole tree. So it seems to me 
that we have to create copies of its children when they change, but I've 
seen discussions about creating branches instead.

How much of this did I get right?




-- 
Brane �ibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/