'cvs update -A' doesn't move to trunk (1.x)

137 views Asked by At

All,

I've recently encountered something in a CVS repo[1] I work on that I've never seen. There is a file in it that is now at 1.1.1.7.2.3 and the developer would like to merge it back to the trunk with the usual cvs upd -j. There is a 1.1 revision, so we'd end up with 1.2. But, something odd is happening:

(432) $ cvs stat lsm_routines.F90
===================================================================
File: lsm_routines.F90  Status: Up-to-date

   Working revision:    1.1.1.7.2.3
   Repository revision: 1.1.1.7.2.3 /cvsroot/esma/esma/src/Components/GEOSland_GridComp/Shared/lsm_routines.F90,v
   Commit Identifier:   10058360F8865121B95
   Sticky Tag:      H54p3NL_RFCST_DEC (revision: 1.1.1.7.2.3)
   Sticky Date:     (none)
   Sticky Options:  (none)

(433) $ cvs upd -A
cvs update: Updating .
P GNUmakefile
P lsm_routines.F90
U update_model_paras.F90
(434) $ cvs stat lsm_routines.F90
===================================================================
File: lsm_routines.F90  Status: Up-to-date

   Working revision:    1.1.1.7
   Repository revision: 1.1.1.7 /cvsroot/esma/esma/src/Components/GEOSland_GridComp/Shared/lsm_routines.F90,v
   Commit Identifier:   cafGCp7ex2ZHRIRy
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

(435) $ 

Note, it's not at 1.1, but at 1.1.1.7. It's like the HEAD isn't the top of the 1.x branch but the top of the 1.1.1.x branch. Huh.

Not every file in that directory does this; for example, the GNUmakefile acts as I'd expect:

(444) $ cvs stat GNUmakefile 
===================================================================
File: GNUmakefile       Status: Up-to-date

   Working revision:    1.1.1.1.4.1
   Repository revision: 1.1.1.1.4.1 /cvsroot/esma/esma/src/Components/GEOSland_GridComp/Shared/GNUmakefile,v
   Commit Identifier:   LNjO62lYlJEM8V4z
   Sticky Tag:      Heracles-UNSTABLE-RanlibFix-ESMF7 (revision: 1.1.1.1.4.1)
   Sticky Date:     (none)
   Sticky Options:  (none)

(445) $ cvs upd -A
cvs update: Updating .
P GNUmakefile
P catch_constants.f90
P lsm_routines.F90
U update_model_paras.F90
(446) $ cvs stat GNUmakefile
===================================================================
File: GNUmakefile       Status: Up-to-date

   Working revision:    1.3
   Repository revision: 1.3 /cvsroot/esma/esma/src/Components/GEOSland_GridComp/Shared/GNUmakefile,v
   Commit Identifier:   jNHU505ZSv5uKViz
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

(447) $ 

1.x is where I'd expect to be.

Has any one ever seen this before in CVS? Is there something on the admin side that could be done? Some weird lock or attribute that needs flipped?

Matt

[1] Just to forestall the inevitable: Yes, I know CVS is old and should be migrated away from; I am helping to move this repo to git soon, but for now, development is in CVS.

1

There are 1 answers

0
Fortran On BEST ANSWER

Well, in the end the answer seems to be: CVS is weird.

I decided to just throw caution to the wind and do the steps I'd normally do and...it ended up at 1.2! Even though it said it was at 1.1.1.7, it committed to 1.2.

shrug

As I said, we are moving to git soon, so, frankly, the CVS can get a bit weird and I don't mind.