On Mon, Jun 8, 2009 at 9:24 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> Marko Käning wrote:
>
>> what are your users running as an operating system? in this situation, it
>>> sounds like a true dcvs would excel. and actually, if your users arent
>>> on
>>> windows, id wholeheartedly recommend git-svn.
>>>
>>
>> I'd also recommend to go for a real distributed VCS!
>>
>> I just learnt on SVK's (another DVCS) mailing list that git is actually
>> even under windows now easy to use with msysGit (
>> http://code.google.com/p/msysgit/)!
>>
>> Perhaps mercurial (www.selenic.com/mercurial) might be another
>> alternative for you!
>>
>
> Distributed VCS's can let you avoid network issues by working in isolation,
> but if your real goal is to allow a number of distributed team members to
> take advantage of each others updates as they are made you are going to have
> to deal with the network transfers anyway - and depending on the nature of
> the project you may really want a central authoritative repository.
yes, you will eventually have to go over the network, but even then another
advantage of dvcs is the inherent ability to compress data. im not sure if
this affects the amount of data sent over the wire on sync operations, but
it wouldnt surprise me if it did.
also, speculation is that as adoption settles in for dvcs, most
organizations / teams / individuals will adopt hybrid models between
centralized and 'fully' distributed models. having one 'central' or
'authoritative' repo will likely be a common practice.
...
having already given some bit of thought to this, i like the notion git
provides of being able to remove history. this affords an opportunity to
really tune repositories for particular purposes. for example, i may retain
an authoritative 'archive' repository, on a highly redundant box, that is
known to be slow, b/c of its wide content boundaries. i may also have
special 'QA' repositories, and 'deployment' repositories, each w/ only a
small amount of data, specifically for the purpose those repos serve.
one thing ive always seen the private sector companies struggle w/ is
promotion of code through the typical tier of 'environments'. such as
devlopment, qa, production, etc.. what happens is code is versioned at the
lowest level, but then managment of changes as they move up the stack to
production is always a circus (my personal exp here of course..). anyway,
what ive always envisioned is use of vcs to manage code as it propagates up
the stack from development to production, and frankly the paradigms ive
arranged in svn dont suit me. dvcs makes designing and implementing this
notion super simple and clean. rather than having a ton of branches and a
hairy naming scheme for said branches you have a bunch of repos. plus
trying to manage the same codebase in multiple svn repos just feels wrong.
dvcs has the concept of guid's which makes the use of multiple repositories
totally natrual.
-nathan
ps
(sorry for the rant)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360405
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-08 20:23:27 CEST