2011-01-16 10 views
5

Ostatnio czytałem ten artykuł: http://www.smashingmagazine.com/2009/09/25/svn-strikes-back-a-serious-vulnerability-found/Korzystanie z SVN w web-development

twórców wielu popularnych witryn takich jak apache.org, php.net (http://ru2.php.net/.svn/entries), classmates.com i rosyjski Yandex używają SVN, ale nie postępuj zgodnie z zaleceniami SVN (aby użyć komendy export).

Tak, jakie są powody, dla których nie używa się svn export zamiast aktualizować kopię publiczną, tak jak wszystko, co robią?

Odpowiedz

2

Z mojego punktu widzenia to, co robię, to blokowanie/blokowanie dostępu do dowolnych plików .svn na serwerze (zarówno Apache2, jak i IIS) w ten sposób, że ukryte foldery nie są dostępne zewnętrznie, i pozwala na śledzenie wersji dla witryn, z których korzystamy. które nie wymagają kompilacji przed rolecie

języków takich jak:

  • PHP
  • ASP (nie .NET)
  • PLAIN HTML
  • COLDFUSION
  • Wersjonowanie PDF/IMAGE (w razie potrzeby potrzebne było dla mnie zaktualizowane dokumenty PDF dla klientów).

Z pewnością można korzystać z SVN do tworzenia stron internetowych, ale trzeba zachować ostrożność, gdy ujawniasz swoje foldery .svn światu, jeśli nie jesteś ostrożny. W przeciwnym razie jest to narzędzie, dzięki któremu Twoja praca będzie łatwiejsza i bardziej wydajna.

Po tym, po prostu uruchomimy SVN UPDATE w naszej produkcji, aby zaktualizować zmienione pliki, a przy ograniczonej liczbie programistów pracujących na jednym kawałku kodu na raz (jak powiedziałem w moim przypadku) nie otrzymujemy mixupów z błędem rzeczy się wdrażają. PLUS Aby być bezpiecznym, zawsze należy wykonać SVN CHECK FOR MODIFICATIONS, aby zobaczyć, co zostanie zaktualizowane, a jeśli popełnisz błąd, wycofaj.

+0

A dlaczego nie używasz' svn export'? – Azat

+1

Ponieważ używamy tylko eksportu SVN dla projektów, które musimy skompilować ** ALE ** tak naprawdę nie robimy tego w ten sposób, ponieważ mamy instalację Hudsona do automatycznego instalowania kompilacji dla nas (ASP.NET + JAVA). – Jakub

4

Niektórzy ludzie, nie licząc mnie, uważają, że do wdrożenia do produkcji wystarczy wydać svn. Jeśli wykonasz eksport, utracisz metadane dotyczące wersji, więc nie możesz tego zrobić, musisz użyć innego mechanizmu do śledzenia, która wersja jest gdzie. Jest to proste rozwiązanie, ale myślę, że może ono zająć leniwy pakunek, a także "mocowanie w produkcji", tak jakbyś to zrobił, możesz także sprawdzić z powrotem z produkcji ...

+0

Muszę jednak powiedzieć, że ta metoda ma nieco więcej zalet, gdy tylko statyczne pliki, takie jak obrazy, HTML i php na przykład. Robi się bardzo źle, gdy masz jsp lub inne rzeczy, w których kod wykonywalny jest jakoś pochodnym obiektem. – time4tea

+0

eksport tak jest, nie chcesz wielu plików .svn w katalogu głównym! – rook

+0

Myślałem, że jeśli przejdziesz do góry, możesz nie przetestować rzeczy, którą wdrożysz, albo zapomnieć o jej oznaczeniu, albo może nie mieć odpowiednich aprobat itp.Wolałbym wdrożyć coś, co zostało przez wszystkie bramy/zatwierdzenia. – time4tea

1

Z plikami svn export nigdy nie zostaną usunięte , tylko dodane i zmodyfikowane. Może to być czasem problem.

+2

to dlaczego eksportujesz do innego katalogu (ów), a następnie 'rsync' do katalogu (-ów) wdrożenia :-) – prodigitalson

0

Gdy cała witryna jest otwarta i dostępna do pobrania za pośrednictwem publicznego źródła (np. PHP's). Ochrona katalogów .svn, aby inne nie mogły uzyskać kodu źródłowego, prawdopodobnie nie jest warta wysiłku, ponieważ po prostu robi się svn up.