Kurumsal dosya deposu için GIT kullanmalı mıyım?

Aynı dosyaları paylaşması gereken (uzaktan ekleme ve düzenleme dahil) bir dizi uzaktan çalışanımız var.

Geçmişte mükemmel sonuçlarla SVN kullandık.

Sahip olduğumuz en büyük SVN reposlarından biri 17GB. Boyut asla problem değildi. Orada her şey vardı, özellikle ikili dosyalar.

Ancak, dezavantaj SVN'nin her klasördeki gizli bir klasörü saklamasının çok kullanıcı dostu olmadığıydı. (Kullanıcılar klasörleri kopyalayıp yapıştırdıklarında).

Git bunu çözüyor gibi görünüyor. Soru Git kullanmalı mıyım, SVN ile çalışmalı mıyım yoksa henüz rastlamadığım başka bir açık kaynak aracı var mı?

1
Kilitleme kullanıyor musunuz?
katma yazar Josh Lee, kaynak
İhtiyaçlarınızı karşılayabilecek birçok DVCS çözümü var. SVN'den hoşlanıyorsanız, ancak .svn dizinlerinden hoşlanmıyorsanız, SVN 1.7'yi kök dizindeki tek bir .svn dizinine taşıdıkları yeri araştırdınız mı?
katma yazar AlG, kaynak
@Josh. Hayır, yapmadık. Sunucuda hangi SVN sürümünün bulunduğuna emin değilim. Ama işe yaradı. Biz esas olarak, pazarlama ekipleri ve inceleme ekipleri arasında teminat oluşturma ve gözden geçirmeyi pazarlama için kullandık.
katma yazar Blake K Peterson, kaynak
@AI. WOW ... 1.7 bir göz atmak zorunda .svn klasörü sorunumuzu çözecektir :)
katma yazar Blake K Peterson, kaynak

5 cevap

Buradaki şeyleri düşünmek üzeresin. Muhtemelen bir kaynak kontrol çözümü istemiyorsunuz. Çalışanlarınız .svn dosyaları tarafından karıştırılıyorsa, bunlar Git ile karıştırılacaktır.

Olası bir çözüm Dropbox . Dropbox, Dropbox adında bir klasöre Linux, Unix ve Mac'te $ HOME dizininizin altında veya Windows'daki Belgelerim klasörünüzün altına yerleştirilir. Orada belirtilen herhangi bir dosya Dropbox sunucusuna senkronize edilecektir.

Başka bir bilgisayara giderseniz ve aynı Dropbox hesabını paylaşırsanız, tüm dosyalar orada da eb. Dropbox Linux, Windows ve Mac'lerde çalışır.

Hepinizin Dropbox hesapları varsa, bu hesaplar arasında paylaşılan klasörler oluşturabilirsiniz. Bir klasörü bu şekilde birden çok kişi arasında paylaşabilirsiniz. Dropbox bazı versiyon mekanizmalarına sahiptir. Bir dosyanın önceki kopyalarını geri alabilirsiniz, böylece bir değişikliği beğenmezseniz, geri alabilirsiniz. Silinen sürümleri bile geri alabilirsiniz.

Dropbox 2GB'lık veri için ücretsizdir ve ödemeye hazırsanız daha fazla alan kazanabilirsiniz. Bu tür bir durum için Dropbox kullanıyorum ve 2Gb hesabı genellikle yeterince iyi.

SugarSync gibi başka benzer hizmetler var, ancak Dropbox'ın mutlak sadeliğini seviyorum. Teknik olmayan kullanıcılar için harika çalışıyor.

David Pogue sadece bir az yazmıştı. hafta önce .

Dropbox'la hiçbir şekilde çalışmadım, işimi büyük ölçüde basitleştirdiğini anlayan bir kullanıcı dışında.

İşte Dropbox Alternatifleri 'nin listesi. Hiçbirine kefil olamam, ama muhtemelen bir göz atmaya değer.

1
katma
Teşekkürler - bir süredir dropbox hakkında bilgi sahibi oldum, muhtemelen daha iyi açık kaynak çözümleri olduğunda ödeme yapmaya pek hevesli değil. SugarSync hakkında bir şey duymadım. Buna bakmayacağım. :)
katma yazar Blake K Peterson, kaynak

Eğer endişelenen ana dezavantajı pek çok .svn gizli klasörler ise, bu artık v1.7'deki gibi değildir.

See Working Copy Metadata Storage Improvements

Subversion 1.7'de sunulan değişikliklerin önemli bir özelliği   çalışma kopyası meta veri depolamanın tek bir merkezde toplanması   yer. Her dizinde bir .svn dizini yerine   çalışma kopyası, Subversion 1.7 çalışma kopyaları sadece bir tane var .svn   dizin - çalışma kopyasının kökünde. Bu dizin içerir   (diğer şeylerin yanı sıra) tümünü içeren bir SQLite destekli veritabanı   Bu çalışan kopya için meta veri Subversion ihtiyacı var.

1
katma
Neden düşüş var?
katma yazar RedFilter, kaynak
@Blake: Bilinmeyen ...
katma yazar RedFilter, kaynak
Teşekkürler ! - SVN'ye geri dönüyorum sanırım :)
katma yazar Blake K Peterson, kaynak
@redFilter ... kime göre?
katma yazar Blake K Peterson, kaynak

17GB bir git deposu için çok büyük olurdu, 1 ve deneyimi katlanılabilir kılmak için bakım ayarı yapılandırma seçeneklerine ihtiyacınız olacaktır.

Çok sayıda büyük ikili dosya sürümünün kullanılması, bunun yerine Subversion kullanmanın makul olduğunu düşündüğüm az sayıda alandan biridir . git veya Mercurial.

1 Yüzlerce gigabayt boyutunda (yedekleme amaçlı) bir git deposunu kullanıyorum, ancak bu, belirsiz bir spordur.

0
katma
Teşekkürler! Evet - Bu çözüm SVN 1.7 gibi görünüyor.
katma yazar Blake K Peterson, kaynak

Git, deponuzdan en üstteki dizine dahili bir .git dizini tutuyor.

Git'te bulduğum başlıca avantaj, tüm tarihin yerel olarak ve büyük fark yaratan dizüstü bilgisayarlar için mevcut olmasıdır.

0
katma
Evet, svn'den gelen ana çekişti.
katma yazar Blake K Peterson, kaynak

VCS'yi yalnızca paylaşılan dosya depolama alanı olarak kullanırsanız, bu görev için fazla ücret uygulanır. Ve SCM'lerin çoğu, ikili dosyaları oldukça zayıf işlemektedir. Çoğunlukla işe yaramaz (özellikle ikili dosyalar için) düzeltme geçmişini saklamak için büyük boyutlu yükünüz var.

Özgeçmiş - Git'e gitmek için nedenleri göremiyorum (hatta SVN'yi kullanıyorum - sıradan WebDAV konumu yeterli olabilir)

0
katma
FS ve oneliner "copy src dst" deki değişiklikleri izlemek için FAM modülü bu şekilde ve neredeyse gerçek zamanlı olarak çalışabilir
katma yazar Lazy Badger, kaynak
Evet durum böyle görünüyor :) Yorumlarınız için teşekkürler. İlk başta, overkill hakkında düşündüm. Ancak, canlı prodüksiyon dosyaları ile bir dizin kullandık ve daha sonra web sitemizdeki bir klasöre bunları kontrol etmek için bir cron kullandık. Bu, web sitesi resimlerini ve teminatlarını güncel tutmak için harika bir çözümdü.
katma yazar Blake K Peterson, kaynak