Message-Id: <m102xJQ-000OW3C@jazzie.com> From: email@example.com (Sean Shapira) To: firstname.lastname@example.org (Geoffrey M. Clemm) Date: Wed, 20 Jan 1999 05:04:47 -0800 (PST) Cc: email@example.com In-Reply-To: <9901200622.AA14143@tantalum> from "Geoffrey M. Clemm" at Jan 20, 99 01:22:27 am Subject: forking on checkin vs. on checkout Hello Geoff and the rest of the versioning design team. Thanks for doing a great job proposing a workable versioning model! Geoff wrote: > Only one checkout of a given mutable-revision (branch) of a versioned > resource, yes. If you want to check-out an already checked-out mutable- > revision (branch), you need to use the CHECKOUT-NEW method, which checks > out a new mutable-revision (branch) of the versioned resource. Does this imply that a fork occurs as soon as a second check-out is performed on a revision? The alternative model delays the fork until the second check-in is performed. That approach has some major benefits, not the least of which is that the second user to check-in can be given the option of merging all the changes and thus avoiding the fork altogether. Another alternative model has the fork happening on check-out, but doesn't give either child revision special status until the first one is checked in. In particular, until a check-in occurs one wouldn't know which child will become the immediate successor on the same branch as their shared parent, and which -- in the absence of a merge -- would be shunted off to a side-branch. Either of these alternatives supports a less structured style of cooperative work, without sacrificing any revision-control rigor. -- Sean Shapira firstname.lastname@example.org +1 206 443 2028 Serving the Net since 1990.