2016-12-21 8 views
0

Все,«резюме -A обновление» не переходит к стволу (1.x)

Я недавно столкнулся что-то в CVS репозиторий [1] я работаю на том, что я никогда не видел. В нем есть файл, который теперь находится в 1.1.1.7.2.3, и разработчик хотел бы объединить его обратно в багажник с обычным cvs upd -j. Существует версия 1.1, поэтому мы получим 1.2. Но происходит что-то странное:

(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) $ 

Примечание. Это не в 1.1, а в 1.1.1.7. Это похоже на то, что HEAD не является вершиной ветки 1.x, а вершиной ветки 1.1.1.x. Да.

Не каждый файл в этом каталоге делает это; например, GNUmakefile действует так, как я ожидал бы:

(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 - это то место, где я ожидал бы быть.

Неужели кто-либо видел это раньше в CVS? Есть ли что-то на стороне администратора, что можно сделать? Какой-то странный замок или атрибут, который нужно перевернуть?

Matt

[1] Просто, чтобы предотвратить неизбежное: Да, я знаю, что CVS стар и должен быть перенесен от; Я помогаю быстро переместить этот репо в git, но пока что разработка находится в CVS.

+0

Существует ли версия 1.1? Или файл существует только в ветке, а версия 1.1 - это удаление (я не уверен на 100%, но я думаю, что CVS может это сделать). Хотя это не повлияет на поведение, которое вы видите в желаемом поведении, возможно, это именно то, что делает CVS в этом случае? – Mort

+1

Кроме того, это CVSNT? Я не думаю, что признаю «Commit Identifier» из обычных cvs. – Mort

ответ

0

Ну, в конце концов, ответ кажется: CVS странно.

Я решил просто бросить осторожность на ветер и сделать шаги, которые я обычно делал, и ... это закончилось в 1.2! Несмотря на то, что он сказал, что он был в 1.1.1.7, он выделил 1,2.

пожимают плечами

Как я уже говорил, мы переходим к мерзавцу в ближайшее время, так, честно говоря, CVS может получить немного странно, и я не возражаю.

 Смежные вопросы

  • Нет связанных вопросов^_^