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