From 3d6662e779dd88368a4fc61e45c4267fd0c2cbcc Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Fri, 13 Jul 2007 18:16:01 +0000 Subject: [PATCH] Brian explains. --- sccs2rcs | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/sccs2rcs b/sccs2rcs index 4de7cbb..6752430 100755 --- a/sccs2rcs +++ b/sccs2rcs @@ -9,10 +9,10 @@ # In 1993 I applied some minor fixes for newer RCS versions and it # shipped as part of one of Rich Morin's Prime Time Freeware releases. # -# At some undetermined time after 1993, Brian Berliner hacked Ken -# Cox's original in a slightly different direction than mine, adding -# more SCCS keyword translations and an improvement in dealing with -# branches. +# In 1994 Brian Berliner hacked Ken Cox's original in a slightly +# different direction than mine, adding more SCCS keyword translations +# and an improvement in dealing with branches. At least, Brian *thinks* +# it was 1994... # # In 2002 I fixed it not to require the Berkeley sccs(1) front end. # In 2003 I folded in a minor bug fix from Roger Pilkey. @@ -290,9 +290,15 @@ if __name__ == '__main__': lckrev = ".".join(revparts[:-1]) if rev.count(".") > 1: # need to lock the branch -- it is OK if the lock fails - # Above comment was from Brian Berliner's csh version, - # but it's not at all clear why this lock can be allowed - # to fail while the trunk one must succeed. + # + # I asked Brian and he explained this as follows: + # "As it turns out, with RCS, if you are adding the + # first revision of a new branch, you don't need + # to lock the trunk. In fact, you don't want to + # lock the trunk because checking in the revision + # on the branch will not unlock the trunk. So, the + # hack I applied was to get it to add branches + # correctly." do_it("rcs -l%s %s" % (lckrev, stem)) record("got branch lock") else: -- 2.43.0