Jak zapisać hasło podczas korzystania z Subversion z konsoli

To zależy od protokołu, którego używasz. Jeśli używasz SVN + SSH, klient SVN nie może zapisać hasła, ponieważ nigdy go nie dotknie - klient SSH poprosi Cię o to bezpośrednio. W takim przypadku można użyć klucza SSH i ssh-agent, aby uniknąć stałych monitów. Jeśli używasz protokołu svnserve lub HTTP(S), to klient SSH obsługuje Twoje hasło i może je zapisać.

Spróbuj wyczyścić swój .subversion folder w katalogu domowym i spróbuj ponownie zatwierdzić. Powinien monitować o podanie hasła, a następnie zapytać, czy chcesz je zapisać.

Musiałem edytować ~/.subversion/servers. Ustawiłem store-plaintext-passwords = yes (wcześniej nie było). Udało się. Można to jednak uznać za niepewne.

Proszę zwrócić uwagę na następujący akapit z pliku ~/.subversion/servers:

Zarówno 'store-passwords' jak i 'store-auth-creds' mogą być teraz określone w pliku 'servers' w katalogu konfiguracyjnym. Wszystko określone w tej sekcji jest zastępowane przez ustawienia określone w pliku "serwery".

Jest to przynajmniej dla wersji SVN 1.6.12. Należy więc pamiętać, aby edytować plik servers również wtedy, gdy nadpisuje ~/.subversion/config.

Jeśli używasz svn + ssh , możesz skopiować swój publiczny klucz ssh na zdalną maszynę:

ssh-copy-id user@remotehost

Dla mnie (użytkownika Mac) problem polegał na tym, że keychain miał już zapisany wpis dla moich poświadczeń, ale prawa dostępu nie były właściwe.

Usunięcie wpisu w aplikacji key chain, a następnie odtworzenie go za pomocą svn rozwiązało problem.

Użycie zwykłego tekstu może nie być najlepszym wyborem, jeśli hasło jest używane jako coś innego.

Popieram przyjętą odpowiedź, ale nie zadziałała dla mnie - z bardzo konkretnego powodu: chciałem użyć albo kwallet, albo gnome-keyring. Próbowałem zmienić ustawienia, wszystkie cztery pliki:

/etc/subversion/config
/etc/subversion/servers
~/.subversion/config
~/.subversion/servers

Nawet po tym, jak wszystko zostało ustawione tak samo, z password-stores i nazwą KWallet (domyślnie może być źle, prawda?) nie zadziałało i ciągle pytało o hasło. Pliki w ~/.subversion miał uprawnienia 600.

Cóż, w tym momencie możesz spróbować sprawdzić jedną prostą rzecz:

which svn

Jeśli otrzymasz:

/usr/bin/local/svn

Wtedy możesz podejrzewać z dużym prawdopodobieństwem, że ten klient został zbudowany ze źródła, lokalnie, przez Twojego administratora(który może być tobą, jak w moim przypadku).

Subversion to paskudna bestia do kompilacji, bardzo łatwa do przypadkowego zbudowania bez wsparcia HTTP lub - jak w moim przykładzie - bez wsparcia dla zaszyfrowanych sklepów z hasłami (potrzebujesz albo Gnome lub KDE development files, i wiele z nich!). Ale skrypt ./configure Ci tego nie powie, a po prostu dostajesz mniej funkcjonalne polecenie svn.

W takim przypadku możesz wrócić do klienta, który przyszedł z Twoją dystrybucją, zwykle w /usr/bin/svn. Minusem jest to, że prawdopodobnie będziesz musiał ponownie sprawdzić kopie robocze, ponieważ nie ma komendy svn downgrade. Możesz skonsultować Linusa Torvaldsa , co w każdym razie myśleć o Subversion;)

Niestety odpowiedzi nie rozwiązały problemu pytania o hasło dla ssh + svn z chronionym kluczem prywatnym. Po kilku badaniach znalazłem:

ssh-add

Narzędzie, jeśli masz komputer z Linuksem. Upewnij się, że masz zapisane klucze w /home/username/.ssh/ i wpisz to polecenie w Terminalu.

Używam klienta TortoiseSVN w systemie Windows i dla mnie ustawienie parametru store-passwords jako yes w %USERPROFILE%\AppData\Roaming\Subversion\config nie pomaga w przechowywaniu hasła.

Hasło zostało pomyślnie zapisane po usunięciu tego folderu (na wszelki wypadek zmiana nazwy):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Środowisko:

Windows 7, TortoiseSVN 1.7.11 (Build 23600 - 64 bit, 2012-12-12t19:08:52), Subversion 1.7.8.