2010-10-15 16 views
56

Podczas gdy w jakiś sposób zorientowany w VCS (zwykły użytkownik svn, git i git-svn) nie mogę oblewać głowy tym dziwnym zachowaniem SVN.Sprytny sposób na zmianę nazwy katalogu w kopii roboczej subversion

Ilekroć trzeba zmienić nazwę katalogu w moim SVN kopii roboczej z inaczej „czystej” państwa - tj svn status nic nie zwraca, a wszystkie inne modyfikacje zostały popełnione - jak więc (co jest, co sugeruje, że doc SVN):

svn mv foo bar 
svn commit 

SVN narzeka głośno:

Adding   bar 
Adding   bar/toto 
Deleting  foo 
svn: Commit failed (details follow): 
svn: Item '/test/foo' is out of date 

Jak chcesz:

svn update 

Co daje:

C foo 
At revision 46. 
Summary of conflicts: 
    Tree conflicts: 1 

Istnieje konflikt drzewo, natomiast bez zmian przez stronę trzecią stało. Oczywiście, jedynym sposobem, aby wyjść z tego konfliktu drzewo bałagan jest rodzajowo (od svn czerwonej książce):

svn resolve --accept working -R . 
svn commit 

Zmiana nazwy to zdalnie na repo następnie zaktualizowaniu kopię roboczą wydaje się dość braindead:

url=$(svn info | grep -e '^URL:' | sed 's/^URL: //') svn mv $url/foo $url/bar 
svn update 

Czy istnieje usankcjonowany, bardziej usprawniony sposób zmiany nazwy folderu, którego mi brakuje? Jaka jest główna przyczyna tego szczególnie zaskakującego stanu konfliktu drzew?

+0

Czy możesz umieścić wiadomość o konflikcie drzewa? –

+0

Te zachowania widziałem również wcześniej, ale nie jestem pewien, co to powoduje. Czy jest to możliwe po dodaniu katalogu i zmianie jego nazwy? –

+0

Ja również doświadczam tego zachowania i nie jestem w stanie znaleźć przyczyny. Zawsze zapisywałem to na "sposób, w jaki działa SVN". Doprowadza mnie to do szału. –

Odpowiedz

56

svn mv roboty dla mnie:

C:\svn\co>svn mv my_dir new_dir 
A   new_dir 
D   my_dir\New Text Document.txt 
D   my_dir 


C:\svn\co>svn commit -m foo 
Raderar    my_dir 
Lägger till   new_dir 

Arkiverade revision 2. 

C:\svn\co> 

Niestety dla szwedzkiej produkcji SVN.

W twoim przypadku musi być coś jeszcze nie tak.

Edit:
Jak zauważył w komentarzach przez Lloeki

Aby odtworzyć problem trzeba także aktualizować i zobowiązać plik znajdujący się w folderze, ale nie aktualizuje sam folder.

plik popełnić tworzy nowy rev N na repo, ale lokalny metadane nie jest aktualizowane (jak to zawsze będzie można znaleźć svn dzienniku po wystąpieniu popełnić), a tym samym reż metadanych jest rev N- 1. Następuje , w której svn nie zostanie zatwierdzone ze względu na różnicę metadanych i nie zaktualizuje , ponieważ rzeczywiście występuje konflikt na w metodzie dir: update vs delete.

Zachowanie jest „oczekiwany” i „rozwiązanie” jest, aby zaktualizować kopię roboczą przed wydaniem komendy svn rename.

+2

Stwierdzenie, że "coś innego" jest rzeczywiście częścią pytania :) Teraz zmodyfikuj Nowy tekst Document.txt, zatwierdz go, następnie mv dir i commit ponownie. – Lloeki

+1

@Lloeki, tak przez modyfikację pliku tekstowego odtwarza konflikt drzewa. Naprawdę wygląda to na błąd, czy przeszukałeś tracker problemów na http://subversion.apache.org/ i/lub złożyłeś tam raport o błędzie? –

+2

W końcu znalazłem powód, który ma sens w sposób podważony: commit pliku tworzy nowy rev * n * na repozytorium, ale lokalne metadane nie są aktualizowane (tak jak zawsze, zobacz "rejestr svn" po zatwierdzeniu) , więc metadane dir mają wartość rev * n-1 *. Wynika z tego, że svn nie zostanie zatwierdzone ze względu na różnicę w metadanych i nie zaktualizuje się, ponieważ rzeczywiście występuje konflikt w katalogu dir: update metadata vs delete. – Lloeki

0

Można by pomyśleć o scenariuszu, w którym katalog został zmieniony w repozytorium przez innego użytkownika. Zmiana nazwy tego samego folderu w kopii roboczej może powodować konflikty drzewa podczas zatwierdzania.

Resolving conflicts pokazuje, jak rozwiązać "konflikty drzew" w subwersji.

+0

Jestem w scenariuszu samotnego dewelopera, w którym nie występuje żadna zewnętrzna zmiana. – Lloeki

1

Ten pracował dla mnie:

vi someotherfile 
...various changes to the other file 
svn mv olddir newdir 
svn commit -m"Moved olddir out of the way" olddir 
svn commit -m"New location of olddir" newdir 
svn update 
svn commit -m"Changed someotherfile" someotherfile 

Podejrzewam, że były różne inne sposoby okrągłe, i że zapewnienie był czysty katalog roboczy przed wykonaniem mv svn również zrobiły podstęp.

7

OK, wpadłem na to - i mogę w końcu zrekonstruować problem z prostą sesją terminalową: problem się dzieje, jeśli svn mv (przenieść/zmienić nazwę) plik; następnie zatwierdzić tę zmianę; następnie (bez najpierw wykonanie svn update), svn mv katalogu nadrzędnego pliku, którego przeniesienie/zmiana nazwy została wcześniej zatwierdzona - i wreszcie zrobić svn commit na zmianę nazwy katalogu - lub jako accepted answer podaje to: "potrzebujesz również zaktualizować i zatwierdzić plik zawarty w folderze, ale nie zaktualizować samego folderu "; ale wszystko to zostało wykonane w katalogu macierzystym (lub raczej przodku). Oto wiersz poleceń dziennik wykazując problemu:

$ cd /tmp 
$ svnadmin create myrepo 
$ svn co file:///tmp/myrepo myrepo-wc 
Checked out revision 0. 

$ cd myrepo-wc/ 
$ mkdir -p dir1/dir2/dir3 
$ svn add dir1/ 
A   dir1 
A   dir1/dir2 
A   dir1/dir2/dir3 

$ svn ci -m 'add dir1/' 
Adding   dir1 
Adding   dir1/dir2 
Adding   dir1/dir2/dir3 

Committed revision 1. 

$ echo test1 >> dir1/dir2/dir3/test1.txt 
$ echo test2 >> dir1/dir2/dir3/test2.txt 
$ svn add dir1/ 
svn: warning: 'dir1' is already under version control 
$ svn add dir1/* 
svn: warning: 'dir1/dir2' is already under version control 
$ svn add dir1/dir2/dir3/* 
A   dir1/dir2/dir3/test1.txt 
A   dir1/dir2/dir3/test2.txt 
$ svn status 
A  dir1/dir2/dir3/test2.txt 
A  dir1/dir2/dir3/test1.txt 
$ svn ci -m 'add dir1/dir2/dir3/*' 
Adding   dir1/dir2/dir3/test1.txt 
Adding   dir1/dir2/dir3/test2.txt 
Transmitting file data .. 
Committed revision 2. 

$ svn mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt 
A   dir1/dir2/dir3/test2X.txt 
D   dir1/dir2/dir3/test2.txt 
$ svn status 
D  dir1/dir2/dir3/test2.txt 
A + dir1/dir2/dir3/test2X.txt 
$ svn ci -m 'mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt' 
Deleting  dir1/dir2/dir3/test2.txt 
Adding   dir1/dir2/dir3/test2X.txt 

Committed revision 3. 

$ svn status 
$ svn mv dir1/dir2/dir3 dir1/dir2/dir3X 
A   dir1/dir2/dir3X 
D   dir1/dir2/dir3/test2X.txt 
D   dir1/dir2/dir3/test1.txt 
D   dir1/dir2/dir3 
$ svn status 
D  dir1/dir2/dir3 
D  dir1/dir2/dir3/test2X.txt 
D  dir1/dir2/dir3/test1.txt 
A + dir1/dir2/dir3X 
D + dir1/dir2/dir3X/test2.txt 
$ svn ci -m 'mv dir1/dir2/dir3 dir1/dir2/dir3X' 
Deleting  dir1/dir2/dir3 
svn: Commit failed (details follow): 
svn: Directory '/dir1/dir2/dir3' is out of date 
$ svn status 
D  dir1/dir2/dir3 
D  dir1/dir2/dir3/test2X.txt 
D  dir1/dir2/dir3/test1.txt 
A + dir1/dir2/dir3X 
D + dir1/dir2/dir3X/test2.txt 
$ svn up 
    C dir1/dir2/dir3 
At revision 3. 
Summary of conflicts: 
    Tree conflicts: 1 

I tak powinno być - robi svn up Po przeniesieniu pliku/zmiana nazwy została comitted; Zauważ, że numery wersji donosi svn status -v zmiany po poleceniu svn update:

$ cd /tmp 
$ rm -rf myrepo* 

$ svnadmin create myrepo 
$ svn co file:///tmp/myrepo myrepo-wc 
Checked out revision 0. 

$ cd myrepo-wc/ 
$ mkdir -p dir1/dir2/dir3 
$ svn add dir1/ 
A   dir1 
A   dir1/dir2 
A   dir1/dir2/dir3 
$ svn ci -m 'add dir1/' 
Adding   dir1 
Adding   dir1/dir2 
Adding   dir1/dir2/dir3 

Committed revision 1. 

$ echo test1 >> dir1/dir2/dir3/test1.txt 
$ echo test2 >> dir1/dir2/dir3/test2.txt 
$ svn add dir1/dir2/dir3/* 
A   dir1/dir2/dir3/test1.txt 
A   dir1/dir2/dir3/test2.txt 
$ svn status 
A  dir1/dir2/dir3/test2.txt 
A  dir1/dir2/dir3/test1.txt 
$ svn ci -m 'add dir1/dir2/dir3/*' 
Adding   dir1/dir2/dir3/test1.txt 
Adding   dir1/dir2/dir3/test2.txt 
Transmitting file data .. 
Committed revision 2. 

$ svn mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt 
A   dir1/dir2/dir3/test2X.txt 
D   dir1/dir2/dir3/test2.txt 
$ svn status 
D  dir1/dir2/dir3/test2.txt 
A + dir1/dir2/dir3/test2X.txt 
$ svn ci -m 'mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt' 
Deleting  dir1/dir2/dir3/test2.txt 
Adding   dir1/dir2/dir3/test2X.txt 

Committed revision 3. 

$ svn status 
$ svn status -v 
       0  0 ?   . 
       1  1 username dir1 
       1  1 username dir1/dir2 
       1  1 username dir1/dir2/dir3 
       3  3 username dir1/dir2/dir3/test2X.txt 
       2  2 username dir1/dir2/dir3/test1.txt 
$ svn up 
At revision 3. 
$ svn status -v 
       3  3 username . 
       3  3 username dir1 
       3  3 username dir1/dir2 
       3  3 username dir1/dir2/dir3 
       3  3 username dir1/dir2/dir3/test2X.txt 
       3  2 username dir1/dir2/dir3/test1.txt 
$ svn mv dir1/dir2/dir3 dir1/dir2/dir3X 
A   dir1/dir2/dir3X 
D   dir1/dir2/dir3/test2X.txt 
D   dir1/dir2/dir3/test1.txt 
D   dir1/dir2/dir3 
$ svn status 
D  dir1/dir2/dir3 
D  dir1/dir2/dir3/test2X.txt 
D  dir1/dir2/dir3/test1.txt 
A + dir1/dir2/dir3X 
$ svn ci -m 'mv dir1/dir2/dir3 dir1/dir2/dir3X' 
Deleting  dir1/dir2/dir3 
Adding   dir1/dir2/dir3X 

Committed revision 4. 

$ svn status 
$ svn status -v 
       3  3 username . 
       3  3 username dir1 
       3  3 username dir1/dir2 
       4  4 username dir1/dir2/dir3X 
       4  4 username dir1/dir2/dir3X/test2X.txt 
       4  4 username dir1/dir2/dir3X/test1.txt 
$ svn up 
At revision 4. 
$ svn status -v 
       4  4 username . 
       4  4 username dir1 
       4  4 username dir1/dir2 
       4  4 username dir1/dir2/dir3X 
       4  4 username dir1/dir2/dir3X/test2X.txt 
       4  4 username dir1/dir2/dir3X/test1.txt 

A PO powiedział - należy zapomnieć zrobić svn update przed nowym ruchu/zmiany nazwy + popełnić, a „Commit failed” wystąpił - następnie można użyć svn resolve --accept working -R ., aby móc zakończyć akcję zatwierdzania.

Powiązane problemy