Greg Hudson wrote: > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: > > "To be a compelling replacement for git/Mercurial", perhaps? > > That seems tough.
Heh. A vision that's simple to attain is hardly a vision. What we can usefully do is identify popular features of git/Mercurial that can usefully be taken alone and that can fit properly into a Subversion architecture. > The major architectural differences between > git/Mercurial/Bazaar and Subversion are: > * No commitment to mixed-revision working copies. That sounds interesting, but I haven't got to grips with what it really means in terms of user work flows, and in what senses it is an important functional restriction versus an advantage. > * Full history of at least one branch is generally stored on clients. I wonder whether full history is logically necessary for the behaviours desired, or just an implementation choice of the existing DCVSs. We might be able to design a system that automatically stores a useful and flexible amount of history locally. It should be usable with a portion of a huge repository without requiring expert configuration. > * DVCS workflow support. We have already discussed some DVCS workflow options at a high level, and it seems that some important concepts such as "off-line commits" will be achievable independently. Such concepts might be a bit less powerful because of not being linked to the full feature set of a DVCS - but still very useful. > For small projects and a certain class of developers, these can be huge > advantages. For huge projects and a different class of developers, > these can be hindrances. > (See also http://svn.haxx.se/dev/archive-2008-04/1020.shtml) Ah yes, that email (from David Glasser) on the subject of what Subversion should and could aim for is a good read. - Julian