On this note, I think that a RISC API for source control might only have four lower-level operations (CREATE, READ, UPDATE, DELETE). A commit would be a set of CREATE/UPDATE/DELETE operations and metadata that can be atomically applied to an existing node in the repository. The repository could be modeled as a tree, growing in the direction of time, each node with unique coordinates (the space/time/metadata deal). I think that Git is somewhat modeled like this, even with the ability to move nodes of the tree around; separate them, reattach them, etc.
Eric
· 1 year ago
You mentioned that branching is just a copy with some extra metadata. The metadata is a crucial part, and is one of the major reasons I use Mercurial now instead of Subversion. Subversion got the idea that branching was just a copy down well, they didn't even have a branch command. The problem was merging branches became very difficult, because there wasn't an easy way to track down when the branch diverged.
As far as the computer is concerned, I think a branch is basically a special case of a copy. I think you should expose branch and copy as very distinct operations to the user though.
Adam Blinkinsop
· 1 year ago
Why should they be distinct operations? You should be able to examine the history of any file/branch/etc. and find out the path it took to get where it was, including where it branched off/was copied from, etc.
Eric
· 1 year ago
They should be different because we don't perceive time the way we perceive space. Sure, you make some nifty physics equations by treating time as just another dimension, along with length, width and height, but trying to visualize something like a rotation around the time axis makes almost no sense.
If you view source control as a directed acyclic graph, like Mercurial does, then I'd agree that branches and copies are both instances of one node having two children. The difference is that a traditional branch is a diverging timeline, but a copy is a diverging "spaceline." In a copy, you're branching in space rather than time, in that now you have two different coordinates within the file namespace that have the same parent node.
Another difference is that you traditionally branch a whole repository, while you'll only copy particular files or perhaps directories within a single repository. In general, I think this is a natural distinction to make, although it may not be universally true. For example, there have been times when I've wanted to spin a certain directory off into its own repository, which is less than intuitive in the source control systems I'm aware of.
I suppose you could resolve this by just viewing a branch as splitting the timeline at the root directory, while a copy is usually splitting at a subdirectory or file somewhere. Then the end result is you basically have a root directory with a bunch of named directories that are the different branches, somewhat like a Subversion repository is laid out. Maybe you've convinced me that branches and copies should be treated the same. I'd still like a "psc (platonic source control) branch" command in addition to the "psc copy" command.
Adam Blinkinsop
· 1 year ago
The other thing to think about here is how distributed source control systems like Git and Mercurial work -- every time someone clones a repository, they're branching off of it. Every separate repository is a branch, and every push or pull (in Mercurial terms, at least) is a merge. Would that be an acceptable "psc branch" command? (I like the name!)
All Comments
As far as the computer is concerned, I think a branch is basically a special case of a copy. I think you should expose branch and copy as very distinct operations to the user though.
If you view source control as a directed acyclic graph, like Mercurial does, then I'd agree that branches and copies are both instances of one node having two children. The difference is that a traditional branch is a diverging timeline, but a copy is a diverging "spaceline." In a copy, you're branching in space rather than time, in that now you have two different coordinates within the file namespace that have the same parent node.
Another difference is that you traditionally branch a whole repository, while you'll only copy particular files or perhaps directories within a single repository. In general, I think this is a natural distinction to make, although it may not be universally true. For example, there have been times when I've wanted to spin a certain directory off into its own repository, which is less than intuitive in the source control systems I'm aware of.
I suppose you could resolve this by just viewing a branch as splitting the timeline at the root directory, while a copy is usually splitting at a subdirectory or file somewhere. Then the end result is you basically have a root directory with a bunch of named directories that are the different branches, somewhat like a Subversion repository is laid out. Maybe you've convinced me that branches and copies should be treated the same. I'd still like a "psc (platonic source control) branch" command in addition to the "psc copy" command.