Let’s not use the automatic CVS feed for a discussion about CVS. (If Paul isn’t yet registered to post, we should make this happen.) Meanwhile, I think it’s important to have enough structure to cope with serious forking. Maybe I don’t understand CVS properly, but I don’t think it’s necessarily just a question of the stable version being the last thing tagged ‘release’. I imagine that there may be a number of distinct versions of Epigram floating about, containing incompatible experiments, all of which are of the moment and should be spatially separated rather than temporally. There’s a pragmatic difference between a branch in the development of one thing and the development of two branches of a thing. The current structure allows for the possibility of the latter at the cost of a tiny number of keystrokes
I think Paul’s point is that CVS does provide for this sort of thing. Creating seperate directories inside CVS is not the way to do it. I don’t know much about CVS but I do think it is important to do these things the right way at the beginning otherwise we may have to pay for it later. This bit of cvs documentation explains the way do it. For this prototypic stage of development it provides the desired spatial seperation, is managed and understood by CVS and makes the relationship between the branches explicit. You do have the concept of a ‘main trunk’ but I don’t think this would be a problem. The main trunk will be the conclusive result to some experiments, the approach you decide to merge back in to support the next set of experiments and branches.
One observation, I would prefer that all the branches should be contained within one repository, i wouldn’t want to be fiddling about updating each seperately (as at least potentially there are two or more branches which are as active and bleeding edge as each other), I want to be able to type ‘cvs update’ and get the latest code ineach of the branches. Also the website requirments would be satisfied by this, i.e. we could have html documentation for the differences in each branch, plus we currently have blog content in cvs, this should not be branched (although it might well be better off somewhere else).
If it’s done this way then it’s not actually that different from Conor’s idea of how it should be.
So I guess the question is, is this possible? I suspect not. I know very little about cvs though so I might be far off the mark.
By the way the only person left to register on the Blog is James M…
I’m trying to understand the cvs way. (James, thanks for the pointer.) If we had multiple versions, say a main ‘public’ version plus experimental versions with universe levels or observational equality or whatever, how would that look on my computer? It seems I’d have separate project directories each mapping to a different branch of the repository. That’s fine, up to a point. This point: what’s the website? Now we have separate versions of the website, which do we put the web? I’d want the developers’ site to document all the current experiments and the relationships between them. It would have to be built from all the branches. It’s a bit of an object-vs-meta question. cvs supports multiple alternative versions of a project; I suspect we may also need a project of multiple parallel versions.
Using CVS branches would provide the maximum amount of information (unbroken history) about how the experiments are related but would still look the same as what you’ve got already in your working copy. Well, sort of… What you would do is checkout each branch into a seperate directory on your machine and keep them up-to-date by running cvs update on them individually. You could of course use a script to automate this. Hence doing things the ‘cvs way’ just gives us the appearance of what we’ve already got on the client but with more information.
The website – Perhaps we should move it up a level then. If it is supposed to document the code as a whole including parallel brances etc. Perhaps we should put some user documentation in the doc directory.
Multiple parallel versions – The major problem I think with parallel development branches is keeping them in sync with changes that should be applied to all of them. I think how you would do this in CVS is to update a working copy of a branch with some specific changes from another branch and then commit the changes. CVS woudn’t know that these changes came from another branch, they would look the same as if they had been the result of manual editing. Not sure what would be the best alternative, subversion doesn’t seem to do any better, arch might be an option.
Be careful with parallel versions though.
I tried it once with Plastic, and it got confusing quite fast. Plus it was a lot of work to resolve the versions when I’d finished.
It might be better to decide which sub-systems really will need parallel development, and then build them into the source? Ie, no need to duplicate (hence complicate) 80% of the material if only 20% might vary.
Maybe it would be useful to look for other projects which needed to do this, and see what techniques they used.
The kind of thing I imagine doing is this: fork a branch; throw out 50% of the functionality; change the representation of terms significantly (hence much humdrum propagation) in order to experiment with some new feature of the underlying theory; decide I’ve done it wrong; abandon the branch; do a good job of adding the functionality to the main version once I’ve learned from my mistakes. Happens all the time. And it will happen for the Observational Epigram experiment. It’s really a different deliverable. I’m now convinced that the bleeding-edge versus stable-release issue is better handled by cvs than by proliferating directories. But perhaps ‘current’ should be renamed ‘official’…
Hello James (McK)!
If this is spam, and we’re a target – how about unlinking this site from other epigram pages, and only telling people its whereabouts by email? Ie, so no web crawler will happen upon it.
I think that would be rather drastic.
We just need to configure wordpress to do some filtering.
This looks good