...and of course the elephant in the living room, svn:externals. :) I've been using DVC (git mostly) more and more these days and enjoying it very much. It works particularly well when I have a self-contained software package. I tend to start a project in SVN with the standard trunk/branches/tags layout and then use git in front of the SVN repo. I make the egg root itself a buildout for a test environment with my favorite but not required development tools. (Of course I test with "python setup.py test" before release when the egg doesn't require any additional deployment details provided by the buildout. I don't want to get into that discussion.) It all works much better than trying to work directly with SVN far beyond the benefits of just being able to work offline. What I want to ask about and still haven't worked out an answer to is how to best manage framework or deployment projects where I am developing a number of eggs in parallel under a buildout that needs to be versioned as well. In this case, I'm finding moving away from svn:externals more painful than I expected. Having an overview of all version control status for all code being developed is very valuable. Now some of this comes down to eggs being overused and I've certainly been guilty of that myself. For example, I used to make separate eggs for all my client specific code (policy, theme, etc.). This is clearly unnecessary and I've switched to using one egg that contians multiple sub-packages for factoring. Even with that, however, I still find the lack of a good "what changes have I made to all sub projects" overview to be rather painful. Maybe this is outside the scope of the individual DVC tool and should be handled by an independent tool that aggregates status across projects. How do others handle this kind of situation? Ross