Hangi sürüm kontrol sistemi tüm yönleri yönetebilir? [kapalı]


17

Birkaç ay önce Subversion ve GIT'e girdim ve hayal kırıklığına uğradım. KAYNAK KODU ile ilgilenirler ancak başka yönleri yoktur. Örneğin, sürüm denetimi altındaki bir web sitesinin dosya / dizin sahipliğini, dosya / dizin okuma ve yazma erişimini, Erişim Denetim Listelerini, zaman damgalarını, veritabanı içeriklerini yönetmesi gerekir. ve harici bağlantılar. Bir aylık yedeklemeden yeniden yükleme kadar mükemmel bir geri dönüş yapabilen bir sürüm kontrol sistemi var mı?


12
Bunun yerine bir yedekleme sistemi ister misiniz?
Macke

2
Web sitenizi Mac'te OS X altında çalıştırmayı düşündünüz mü? Time Machine belki de şu anda mevcut olan en basit yedekleme çözümüdür ve gerekirse geri almayı çok kolaylaştırır.

1
Eğer konuyla ciddi bir şekilde ilgileniyorsanız, dosya sistemlerini sürümlendirme ve kaynak kodu için sürüm kontrol sistemlerinin ötesine geçen sürüm veritabanlarında araştırmalara bakmalısınız.
Jakob

scm'nin işlemediği bu tür şeyleri işlemek için biraz komut dosyası yazmanın nesi yanlış? bu şekilde istediğinizi elde edersiniz ve kaynak kontrolü altına alırsınız.
Newtopian

Yanıtlar:


44

Bir sürüm kontrol sisteminin rolü hakkında kafanız karıştı. Çalışan bir web sitesi için bir yedekleme sistemi değildir ve hiç tasarlanmamıştır. Statik içeriği yönetmek için son derece iyi bir iş çıkarır, böylece kontrollü bir şekilde üretime geçer. Etiketleme ve otomatik kullanıma alma işlemlerinin doğru kullanımı sayesinde hızlı değişen siteler bile sürüm kontrol sisteminde tutulabilir.

Bir sürüm kontrol sistemi, sitenin geçen ay neye benzediğinden bugün nasıl göründüğüne (en azından kaynak kontrolü altındaki bileşenler için) nasıl bir şekilde sahip olduğunuzu söyleyebilecektir. Web sitesini yeniden oluşturmak için ihtiyacınız olan her şeyi içermelidir (dinamik içerik hariç). Diğerlerinin de belirttiği gibi, izinlerde ve sahiplikte yapılan değişiklikler komut dosyası olmalı ve komut dosyası sürüm denetimine dahil edilmelidir.

Web siteleri için erişim izinleri genellikle oldukça basittir. (Temel olarak, web sunucusunun tüm içeriği okuyabildiğinden ve çok az yazabildiğinden emin olmanız gerekir.) Web sunucusu altyazısı tarafından yazılabilir olması ve muhtemelen git olması gereken birkaç dizinin dizin sahipliği dışında kesinlikle izinleri işlemek. Web sunucusu tarafından yazılabilir dizinler genellikle web sitesi kaynağından ayrı olarak yönetilen dinamik içerik (web sitesinden oluşturulan ve güncellenen) içerir.

Web sitenizde karmaşık izinlere ve EKL'lere sahip bir web sitesiyle çalışmam istenseydi, web sitesini yönetmek için kullanılan süreçle ilgili ciddi endişelerim olur. Bir sürüm kontrol sistemi uygulamak ve ACL'leri bu sisteme taşımak, ciddi olarak dikkate alacağım çözümlerden biri olacaktır.

Blog girişleri veya yorumlar gibi dinamik içerik, siteyi oluşturmak için kullanılan sürüm kontrolü yerine genellikle bir veritabanında veya başka bir veri deposunda bulunur. Veri deposu, içeriğinin sürüm kontrolünü sağlayacak şekilde düzenlenebilir (bu yazılım gibi). Birçok Wikis, revizyonları izlemek için bir sürüm kontrol sistemi kullanır.

DÜZENLE:

Kullandığım düzeltme (a) Hiç sürüm kontrolü yok, (b) Üretim sitesi ana sitedir, (c) Her değişiklik olduğunda arşivleyin, (d) Arşiv komut dosyası ACL gibi önemsiz öğeleri kaldırır ve (e) yükleme komut dosyası, dosya izinleri gibi diğer gereksiz dosyaları düzeltir.

Bu sorunlar, sitenin bir sürüm kontrol sistemine aktarılması ve işlemin ana sitenin bu sistem üzerinden güncellenmesi için değiştirilmesiyle çözülebilir. (a), (b) ve (c) doğrudan sürüm kontrolü ile ele alınır. (C) 'nin daha iyi çalışması için sürümleri etiketlemek isteyebilirsiniz. (d) dağıtım sitenizi yalnızca sitenizi değiştirdiyseniz, genellikle sorun olmaz. Site içeriğinde ACL'lere hiç ihtiyacım olmadı.

(e) yalnızca ilk oluşturma ve büyük değişiklikler üzerinde çalıştırılması gerekir. Siteyi sürüm denetiminden güncelleyen ve sık çalışan bir komut dosyası da içerebilir. Sitenizi kaçınma kontrol sisteminde tuttuğunuzda bu komut dosyaları oldukça basit olma eğilimindedir.

Ama neden kimse bunu yapmak için genel bir sistem inşa etmedi?

Çünkü bir sürüm kontrol sistemi kullanmanız gerekmiyor.

Bir sürüm kontrol sistemi tüm bu şeyleri takip edebilir, ancak hiçbiri izleyemez.

Hem CVS hem de Subversion, bunları kullanıyorsanız izlemeniz gerekenleri izler. İzlemeniz gereken şeyi izlemeyeceklerdir, çünkü bir sürüm kontrol sistemi kullanmıyorsunuz veya kullanmamalısınız. Bir sürüm kontrol sistemi kullanırken izlemeniz gerekenleri izlerler.

Sürüm denetimini kullanarak içeriklerini yöneten birkaç siteyle çalıştım. Hepsinin siteleri hazırlama, dağıtım sıklığı ve güncellemelerin eksiksizliği için farklı gereksinimleri vardı. Siteler sürüm kontrolünde olduktan sonra, gereksinimlerin geri kalanını karşılamak nispeten kolaydı. Hem CVS hem de Subversion belgeleri, olası güncelleme yöntemleri için önerilerde bulunur.

Sürüm kontrollü içerik içindeki belirli alanlara erişimi sınırlamak için EKL'lere ihtiyacınız olabilir. Ancak, güvene dayalı çalışma eğilimindeyim. Sürüm kontrolü, kimin ne zaman ne yaptığını görmeyi kolaylaştırır. Dosyaları yeniden biçimlendirmezseniz, kimin hangi satırları ne zaman eklediğini gösteren bir dosyanın ek açıklamalı geçmişine sahip olmak kolaydır.


Sorunun en başından itibaren yanlış olmasının nedenlerini ortadan kaldırmak için +1.
Macke

2
+1 Yine de, başkalarının cevabınızdan yararlanabilmesi için sorunun sorulması iyidir.
oliver-clare

Bir sürüm kontrol sisteminin bana "Tamam, buradaki diğer bilgisayarda, 28 Temmuz itibariyle siteyi inşa et" diyebilme yeteneği vermesi gerekiyor. Sürüm kontrolü değişiklikleri izlediğinden yedeklemelerden daha verimlidir. Aksi takdirde, evet, günlük yedekleme işi tamamlar.
Andy Canfield

Evet, kullandığım düzeltme (a) Hiç sürüm kontrolü yok, (b) Üretim sitesi ana sitedir, (c) Her değişiklik olduğunda arşivleyin, (d) Arşiv komut dosyası ACL gibi önemsiz öğeleri kaldırır ve ( e) kurulum betiği, dosya izinleri gibi diğer gereksiz dosyaları düzeltir. Ama neden kimse bunu yapmak için genel bir sistem inşa etmedi? Bir sürüm kontrol sistemi tüm bu şeyleri takip edebilir, ancak hiçbiri izleyemez.
Andy Canfield

+1: Harika cevap. Ancak ben onlar COULDN'T çünkü hiçbir sürüm kontrol sistemi bu şeyler izler eklemek istiyorum. İzinler ve kullanıcı adları ana bilgisayara özgüdür ve biçimleri sisteme özgüdür; aracın, özellikle farklı işletim sistemi olduğunda, bunları farklı ana bilgisayara otomatik olarak bağlayabilmesinin bir yolu yoktur.
Jan Hudec

10

Hepsi ve hiçbiri.

Bu ayrıntıları doğrudan sorunuzun sorguladığı şekilde yönetmek için kaynak kontrolüne sahip olmak kötü bir fikirdir.

Ancak, bu hedeflerin herhangi birini veya tümünü gerçekleştiren bir bash betiği (* nix) veya powershell betiği (Windows) yazabilirsiniz. Bu komut dosyası kaynak denetiminde depolanabilir.

Ardından bu komut dosyasını derleme eserlerinizden biri haline getirebilir ve dağıtımınızın bir parçası olarak çalıştırabilirsiniz.


Bu. Kaynaklara sahip olma fikri, bunları VCS'nizden çıkarabilir ve bitmiş ürünü oluşturmak için kullanabilirsiniz.
Blrfl

2

IMHO kendi başına bir versiyon kontrol sisteminin bu şekilde kullanılması amaçlanmamıştır.

Ama yapmaya eğilimli olduğumdan, yalnızca tek bir derleme dosyası / powershell dosyası çalıştırmanız gereken her şeyi tekrar çalıştırabileceğiniz kaynak kontrolünden bir sürüm alabileceğinizden emin olmaktır.

Bunun için yapmanız gerekenler:

  • uyguladığınız tüm kütüphaneler kaynak kontrolüne bağlıdır
  • ortamınızı ayarlayan bir yapı dosyası
  • ortamınızın gereksinimleriyle ilgili bir talimat (kaynak kontrolünüze bir sql server kurulumu koymak istemezsiniz)

1

Sizin durumunuzda neye ihtiyacınız olduğunu bir yapılandırma yönetim aracı olduğuna inanıyorum . Kullandığım kukla .

Size alıntı:

dosya / dizin sahipliğini, dosya / dizin okuma ve yazma erişimini yönetme,

Ben bir satır ile yaptım (kullanıcı var sağlamak, dizin var, vb sağlamak) ...

Erişim Kontrol Listeleri,

Bu Windows ACL'leri ise, pencereler için belirli CM araçları vardır ...

zaman damgaları,

yine bir kukla betiğindeki bir satırdaki dokunmatik unix komutu bunu sizin için yapabilirdi.

veritabanı içeriği.

Bu birçok çerçevede inşa edilmiş, aksi takdirde her şeyin var olmasını sağlayan bir cron işi mi?

ve harici bağlantılar.

Bunun hakkında hiçbir şey bilmiyorum.

Elbette Yapılandırma Yönetimi kodunuzu yazdıktan sonra, bir sürüm kontrol sistemine koymak (veya ilgili sistemlerde almak) isteyebilirsiniz. Onlardan uzak durmayacaksın :-).


Ne demek istediğini anlamıyorum "timestamps - yine bir kukla komut dosyasında bir satırda bir unix komutu bunu yapabilirdi". Sitemde, site sürümünü almak için sitenin tamamını tarar ve en yeni dosyanın tarih ve saatini döndürür. Benim sürüm denetimi "Checkout" dosyaları 'şimdi' olarak ayarlanmamış, check-in vardı aynı zaman damgası vermek istiyorum. Bunu tek bir unix komutunda nasıl yaparsınız?
Andy Canfield

tabii ki, "dokunma" arıyorsanız, bunu kontrol edin: en.wikipedia.org/wiki/Touch_(Unix) . Genellikle şu an kontrol edilirken zaman uygulanır, ancak herhangi bir nedenden dolayı farklı bir zaman damgası istiyorsanız, bu nasıl yapılır.
Dimitrios Mistriotis

Aslında sorunuzun mantığını beğendim, mümkün olduğunca otomatikleştirmek istiyorsunuz, bu da “doğru yol”, nasıl yapılacağı ve VControl'e neyin gitmediği ve neyin gitmediği hakkında biraz bilgiye ihtiyacınız var. Keşke endüstride daha fazla insan benzer
düşünseydi

0

Tüm dijital belgelerin tüm yönlerini yöneten nihai bir sürüm kontrol sistemi vardır. Buna Xanadu deniyor ve 1960 yılında Theodor Holm Nelson tarafından dosya sistemleri gibi şeyler yaygın olmadan önce yaratıldı . Yani teoride her şey mükemmel bir şekilde çözüldü. Uygulamada, Xanadu hiçbir zaman Nelson tarafından öngörülen şekilde uygulanmadı, ancak Web ve sürüm kontrol sistemleri de dahil olmak üzere daha birçok özel sisteme ilham verdi. Nelson'un çalışmaları hala yeni bir okumaya değer - ve neden tüm yönleri yöneten genel bir VCS olmadığı sorusuna cevap verebilirler.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.