Whole tree up to date before committing

John Arbash Meinel john at arbash-meinel.com
Thu Oct 22 17:29:22 BST 2009

Hash: SHA1

Óscar Fuentes wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
>> Óscar Fuentes wrote:
>>> I don't see this as an advantage, quite the contrary. On mildly active
>>> projects one could find himself doing a merge after another, without a
>>> chance for committing.[snip]
>> This is why you work in branches,
> We are discussing the centralized model here. Which is more popular
> than it seems: given enough developers, distributed models are
> indistinguishable from centralized models (wrt the topic we are
> discussing.)
> For the rest of your message, I'm afraid you confirmed my concerns. I
> was hoping to receive a reply of the type "this issue can be solved
> using technique X and so you can go back to home while dinner is still
> warm." Now I know to which projects *not* recommend bzr (which
> nevertheless is my favourite vcs, being the lack of externals the only
> serious gripe I found so far coming from svn).

So yes, it is by design that we do this. I'll caution that while svn
seems easier it really subtly breaks what you are doing. (what you have
at 'svn ci' is not what you get with 'svn co'.) That specific 'feature'
of svn is not one that we are going to replicate.

If you have a large amount of code with unrelated things, the
recommendation is to split that up into separate projects (with their
own collection of branches). With clearly defined boundaries of what
files should stay synchronized. (If it is truly unrelated, then it
should be in a different branch.)

I realize that the lack of 'svn:externals' complicates this, since after
splitting there isn't a simple 'give me everything' command. Though the
'scmproj' plugin provides a decent set of tools for handling things in a
fashion similar to 'svn:externals'.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the bazaar mailing list