Nathan Nobbe wrote:
> On Mon, Jun 8, 2009 at 9:04 AM, David Weintraub <qazwart_at_gmail.com
> <mailto:qazwart_at_gmail.com>> wrote:
> On Mon, Jun 8, 2009 at 4:49 AM, Marko Käning <mk362_at_mch.osram.de
> <mailto:mk362_at_mch.osram.de>> 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!
> Sooner or later, even distributed repositories have to send
> information back over the network back to the original repository.
> And, if there are network issues, then you'll have the same issues
> all over again.
> i think youll find yourself hitting the network much less often than you
> do as for other operations. lets take a quick look,
> diff, log, merge, co, branch
diff doesn't require network IO unless you are different different revisions
than you have in your working copy. 90% of the time you're doing a diff with
the local changes you have and this requires no network IO.
> scalability is only one problem dvcs attempts to address.. it just
> happens that its turning out better than conventional centralized
> systems on several levels. one amazing aspect for example is that it
> scales beautifully and naturally, and yet, its also way more convenient
> for small personal projects as well. its so much easier to cd into a
> new directory and quickly ordain it as being versioned than it is to
> roll out a new repo in any of a number of centralized systems including
> svn. in fact, as youll see once you start working w/ dvcs tools,
> limitations in conventional tools encourage bad practices, like putting
> several projects into a single repo, which frequents centralized systems.
There's really nothing bad about putting multiple projects into a single repository.
> this is true, however, see above for the overall advantages of dvcs; esp
> in this case. offline working greatly increases performance (thats just
> one benefit).
There is a downside that it can encourage developers to work in their own
repository until the code is "perfect" and then drop a code bomb into the main
repository, at which point it's too late to do any review of the design and the
BTW, I do use git-svn to do checkouts from a Subversion repository, so I like
the features it has, I'm just raising points.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-08 20:31:52 CEST