On Dec 12, 2010, at 8:14 AM, Scott Merrill <[email protected]> wrote:
> On Sat, Dec 11, 2010 at 10:20 PM, Owen Winkler <[email protected]> wrote: >> Git also offers the traditional advantages of distributed SCM, in that I >> could work on a feature to completion locally with the benefit of local SCM, >> and when the feature was complete enough, could push it to the central repo >> where everyone else could use it. The advantage is that features added by >> single developers that aren't ready for distribution wouldn't be introduced >> to everyone in their incomplete state, but those developers would be able to >> maintain their own versioning locally on their work. This is not possible >> with svn alone. > > I was under the impression that we specifically wanted to discourage > this kind of isolated development. I thought the whole point of using > SVN branches was to allow folks to work on new, potentially broken > stuff in a visible, open-to-the-community fashion, so that other > developers could lend a hand, or at least keep an eye on the > goings-on. The local repositories made available via git are useful for creating local, private "branches" for wholly experimental purposes or simply to keep revisions of different attempts at solving a specific small problem isolated before committing it to the repo for everyone to collaborate. It doesn't exclude what we're doing with branches already, but adds additional useful capabilities, namely the ability to track local atomic changes during initial or subsequent experimental development. This feature wouldn't necessarily discourage collaboration. There is a significant amount of code that I lose simply because what I've produced is not ready for public consumption (read "doesn't work, breaks things significantly, and might not be ultimately useful anyway") but subsequent commits by others tread on the same code, and I'm forced to toss my changes to keep my local copy up to date. It's hard to track the code that I produce with this experimental intent, and creating new core repo branches for every whim I have is very impractical. Even if major features were added by some single developer this way, there would ultimately be a pull request that could result in a new public branch in the core repo. This isn't any different from someone making major changes over a month and then committing them all at once into a new svn branch, except that in the git scenario, the developer had the support of a VCS the whole time. Useful. I see this feature more as a potential advantage, not a detriment. Owen -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
