Kurumsal dosya deposu için GIT kullanmalı mıyım?
toplum (2) svn git file-sharing
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ı?
katma 27 Ekim 2011 en 09:57 yazar Blake K Peterson
Kilitleme kullanıyor musunuz?
katma 27 Ekim 2011 en 09:58, 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 27 Ekim 2011 en 10:00, 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 28 Ekim 2011 en 01:40, yazar Blake K Peterson, kaynak
@AI. WOW ... 1.7 bir göz atmak zorunda .svn klasörü sorunumuzu çözecektir :)
katma 28 Ekim 2011 en 01:41, yazar Blake K Peterson, kaynak
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.
katma 27 Ekim 2011 en 11:32 yazar David W.
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 28 Ekim 2011 en 01:38, 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.
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.
katma 27 Ekim 2011 en 10:00 yazar RedFilter
katma 28 Ekim 2011 en 09:09, yazar RedFilter, kaynak
@Blake: Bilinmeyen ...
katma 29 Ekim 2011 en 06:20, yazar RedFilter, kaynak
Teşekkürler ! - SVN'ye geri dönüyorum sanırım :)
@redFilter ... kime göre?
katma 29 Ekim 2011 en 12:26, 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.
katma 27 Ekim 2011 en 10:12 yazar Mark Longair
Teşekkürler! Evet - Bu çözüm SVN 1.7 gibi görünüyor.
katma 28 Ekim 2011 en 01:44, 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.
katma 27 Ekim 2011 en 10:00 yazar Basile Starynkevitch
Evet, svn'den gelen ana çekişti.
katma 28 Ekim 2011 en 01:39, 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)
katma 27 Ekim 2011 en 10:24 yazar Lazy Badger
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 28 Ekim 2011 en 03:06, 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 28 Ekim 2011 en 01:43, yazar Blake K Peterson, kaynak