(I think the subject line no longer applies) Greg Woods wrote: > (There could be a bit of a chicken&egg problem to solve for ".base" > though -- I think you actually have to create it if you want it because > of the late branching optimisation, which is something you cannot avoid > if you want to maintain repo compatability.) I don't understand what you mean. By "create it" do you mean create some actual "x.base" tags in the RCS files? I know, that given only a revision number, that revision may be on multiple branches and each of those branches might have a different ".base", so computing ".base" given only a revision number is not in the general case, possible. (hence it is not (always) possible to reconstruct a lost branch tag.) However, given a branch tag name, x, instead of a revision number, then "x.base" may be calculated easily, right? (by using RCS_whatbranch() and then doing what's done at the beginning of RCS_getdatebranch() ) And I think in this case, we'd always have the branch tag..., if I understand John C's proposal right for <branchname>.base correctly. Alos, I think I mistakenly confused BASE with this "<branchname>.base"..., as I understand BASE, it refers to the revisions that you originally checked out, whatever they may, without any changes that you've made in your working directory, correct? So If that's correct, then BASE is very different than this "branchname.base" proposal. Maybe we should call it something different, "branchname.fork" or "branchname.origin" or something, (supposing somebody has time to look at doing it. -- steve
