Avi Bryant wrote:
> Yes, branching is needed.  What you're describing there is more or less
> how CVS does things - always merge on the client side, and explicitly
> branch the working copy when needed.  The other model I'm considering is
> how I'm told StORE does things - every commit is effectively a branch, and
> you can ask the server to merge any two whenever you want.  With that
> model, there's no merging on the client side - any update is
> effectively a checkout.

I probably have the Envy model in mind (which in this regard is very similar
to StORE) since I've never used CVS or StORE to any great extent.  I also
built an Envy clone (the ObjectStudio team edition) which behaves almost
identically to Envy.  And, I've used quite a few commercial file based tools
(ClearCase being the main one).  What I like about the direction you've
taken so far is that you've restricted the publishing/versioning to the
package level and you're creating a semantic model of the sources.  As far
as the CVS model vs the StORE model, I don't think you need to chose between
the two.  What I was suggesting is that you give the user the change to "opt
out" of introducing a branch when they are about to commit changes that
would create a branch.  If they choose to go ahead with a branch, then you
should also allow them to come back at any time in the future and perform a
merge (and you'll probably want some annotation that a merge happened since
VersionNumber can't implicitly express that a merge took place).  A nice
three-way merge tool will be nice to add (which could be used when you're
trying to avoid a branch (i.e. merge the code in my image with the latest in
the repository) or when you're merging two existing branches).  The 3-way
tool would show you the deltas between each branch and their common base
version (which VersionNumber can tell you).  We had this in the ObjectStudio
team edition and it made life a lot simpler (as compared with Envy).
Merging went from being a complex time consuming operation to being trivial
in even the most complex scenarios.  Having a tool like that enables you to
more clearly see the intention of the changes that were made in each branch
(sort of like being able to see the forest despite the trees).

> Stephen, a question about VersionNumber - can you build a coherent
> VersionHistory from a set of VersionNumbers, or is there some additional
> state that needs to be kept?  Just wondering if I'd need to serialize a
> VersionHistory instance for each repository.

The intention from the start was to allow a VersionHistory to be created
from a simple listing of VersionNumbers (which means you could assemble a
VersionHistory from a set of file names that have VersionNumbers embedded in
them).  You may need to add method or two to VersionHistory though...you'll
probably want a method to initialize a VersionHistory with a set of
VersionNumbers and then validate.  I have rules in VersionHistory about how
versions are allowed to be added/removed (i.e. I don't allow a VersionNumber
that is the basis of two branches to be removed because that version would
be needed in a 3-way merge operation).

> As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn
> lightweight, but since you'll notice that there's only a small and well
> separated bit of code that deals with the remote repository access, feel
> free to send me an alternate implementation.  I'd be happy to lose some
> dependencies.

After using a local repository, it seems that maybe XML-RPC might not be the
bottle neck I thought it was (of course, I'm also running on my 4 year old
266mhz backup machine right now...so everything is sloooow).

- Stephen