Moet ik GIT gebruiken voor een respresentatie van een bedrijfsdossier?

We hebben een aantal externe werknemers over de hele wereld die dezelfde bestanden moeten delen (inclusief toevoegen aan en bewerken).

We hebben in het verleden SVN gebruikt met fantastische resultaten.

Een van de grootste SVN-repo's die we hadden, was 17 GB. De grootte was nooit het probleem. We hadden daar allerlei dingen, voornamelijk binaire bestanden.

Het nadeel was echter dat SVN een verborgen map in elke map opslaat is niet al te gebruiksvriendelijk. (Esp wanneer gebruikers mappen kopiëren en plakken).

Git lijkt dit op te lossen. De vraag is moet ik Git gebruiken, vasthouden aan SVN of is er een andere open source tool die ik nog niet tegengekomen ben?

1
Gebruik je vergrendeling?
toegevoegd de auteur Josh Lee, de bron
Er zijn veel DVCS-oplossingen die aan uw behoeften kunnen voldoen. Als je van SVN houdt, maar een hekel hebt aan de .svn-directory's, heb je SVN 1.7 dan onderzocht waar ze het naar een enkele .svn-map in de root hebben verplaatst?
toegevoegd de auteur AlG, de bron
@Josh. Nee dat deden we niet. Ik weet niet zeker welke versie van SVN we op de server hadden. Maar het werkte. We hebben het voornamelijk gebruikt voor marketingdoeleinden en het beoordelen van marketingteams en beoordelingsteams.
toegevoegd de auteur Blake K Peterson, de bron
@AI. WOW ... moet in 1.7 kijken. Een .svn-map zou ons probleem oplossen :)
toegevoegd de auteur Blake K Peterson, de bron

5 antwoord

Je bent hier over dingen aan het denken. U wilt waarschijnlijk geen oplossing voor bronbeheer. Als uw werknemers in de war raken door de .svn -bestanden, worden ze in de war gebracht met Git.

Een mogelijke oplossing is Dropbox . Dropbox plaatst een map met de naam Dropbox onder je $ HOME-map op Linux, Unix en Mac, of onder je map Mijn documenten in Windows. Elk bestand dat daar wordt geplaatst, wordt gesynchroniseerd met de Dropbox-server.

Als je naar een andere computer gaat en hetzelfde Dropbox-account deelt, zullen alle bestanden ook daar zichtbaar zijn. Dropbox werkt op Linux, Windows en Macs.

Als u allemaal Dropbox-accounts hebt, kunt u gedeelde mappen maken tussen die accounts. Je kunt op die manier een map delen tussen meerdere mensen. Dropbox heeft enkele versie-mechanismen. U kunt eerdere exemplaren van een bestand terugkrijgen, dus als u een wijziging niet leuk vindt, kunt u deze terugdraaien. U kunt zelfs verwijderde versies terughalen.

Dropbox is gratis voor 2 GB aan gegevens en je kunt meer ruimte krijgen als je bereid bent te betalen. Ik gebruik Dropbox voor dit soort situaties en het 2Gb-account is meestal goed genoeg.

Er zijn andere vergelijkbare services zoals SugarSync , maar ik vind Dropbox's absolute eenvoud erg prettig. Het werkt geweldig voor niet-technische gebruikers.

David Pogue heeft net een bericht geschreven slechts een paar paar weken geleden .

Ik ben op geen enkele manier verbonden met Dropbox, behalve als een gebruiker die heeft ontdekt dat mijn werk enorm is vereenvoudigd.

Hier is een lijst met Dropbox-alternatieven . Ik kan niet instaan ​​voor elk van hen, maar ze zijn waarschijnlijk de moeite waard om te bekijken.

1
toegevoegd
Bedankt - ik ken al enige tijd over dropbox, ik ben niet zo happig op betalen als er waarschijnlijk betere open source-oplossingen zijn. Ik heb niets gehoord over SugarSync. Ik zal daar zeker naar kijken. :)
toegevoegd de auteur Blake K Peterson, de bron

Als het grootste nadeel waarover u zich zorgen maakt de vele .svn-mappen zijn, is dit vanaf versie 1.7 niet meer het geval.

See Working Copy Metadata Storage Improvements

Een belangrijk kenmerk van de wijzigingen die zijn geïntroduceerd in Subversion 1.7 is de   centralisatie van metadata-opslag voor werkcopie in één   plaats. In plaats van een .svn-map in elke directory in de   werkkopie, Subversion 1.7 werkkopieën hebben slechts één .svn   map - in de hoofdmap van de werkkopie. Deze map bevat   (onder andere) een door SQLite ondersteunde database die alles bevat   de metadata die Subversion nodig heeft voor die werkkopie.

1
toegevoegd
Waarom het downvote?
toegevoegd de auteur RedFilter, de bron
@Blake: Unknown ...
toegevoegd de auteur RedFilter, de bron
Bedankt ! - terug naar SVN, vermoed ik :)
toegevoegd de auteur Blake K Peterson, de bron
@redFilter ... door wie?
toegevoegd de auteur Blake K Peterson, de bron

17 GB zou erg groot zijn voor een git repository, 1 en je zou zorginstellingen moeten instellen om de ervaring draaglijk te maken.

Het gebruik van versiebeheer van grote binaire bestanden is een van de enkele gebieden waar ik denk dat het redelijk is om Subversion toch te gebruiken van git of Mercurial.

1 Ik gebruik wel een git-repository die honderden gigabytes groot is (voor back-updoeleinden), maar dit is iets van een obscure sport.

0
toegevoegd
Bedankt! Ja - Het lijkt erop dat dat de oplossing is SVN 1.7.
toegevoegd de auteur Blake K Peterson, de bron

Git houdt een interne .git map in de bovenste map van je repository.

Het belangrijkste voordeel dat ik in Git vind, is dat alle geschiedenis lokaal beschikbaar is, en voor laptops die een enorm verschil maken.

0
toegevoegd
Ja dat was de grootste aantrekkingskracht van svn.
toegevoegd de auteur Blake K Peterson, de bron

Als u VCS alleen als gedeelde bestandsopslag gebruikt, is dit overkill voor een dergelijke taak. En de meeste SCM's verwerken binaire bestanden vrij slecht . Je hebt gigantische overhead in grootte voor het opslaan van meestal nutteloze (voor binaries vooral) revisiegeschiedenis

Hervatten - Ik kan geen redenen zien om naar Git te gaan (en zelfs SVN te gebruiken - gewone WebDAV-locatie kan voldoende zijn)

0
toegevoegd
FAM-module voor het bewaken van wijzigingen in FS en oneliner "copy src dst" werkt mogelijk op deze manier en bijna in realtime
toegevoegd de auteur Lazy Badger, de bron
Ja lijkt het geval te zijn :) Bedankt voor je reacties. Ik dacht aanvankelijk eerst aan overkill. We hebben echter één directory met live productiebestanden gebruikt en vervolgens een cron gebruikt om deze naar een map op onze website te controleren. Dit was een geweldige oplossing om websiteafbeeldingen en -materiaal up-to-date te houden.
toegevoegd de auteur Blake K Peterson, de bron