Nathan Nobbe wrote:
>
>
> 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.
I thought subversion did this on http(s):// URLs. And if you need it,
you probably already have it in a VPN transport layer.
> 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.
Yes, but that's an issue with subversion that should be made easier.
> 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.
This doesn't seem like an inherent subversion problem as long as
everyone has sufficient network access. What's wrong with branching for
QA, tagging for production?
> 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.
A hairy mishmash of repositories doesn't sound better than a sensible
branch/tag scheme with a single point that has the entire log/history of
all the contents.
> plus trying to manage the same
> codebase in multiple svn repos just feels wrong.
Yes, that would be wrong - but branches and tags are fine.
> dvcs has the concept
> of guid's which makes the use of multiple repositories totally natrual.
Maybe - I'd always wonder if there weren't disconnected pieces that
should have been merged.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360416
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-08 21:01:33 CEST