Lester Caine <les...@lsces.co.uk> writes: > jeremiah.do...@gmail.com wrote: >> I hope that clarifies things a bit. It definitely doesn't make grokking >> things a whole lot easier, and it is certainly *possible* to follow a >> very svnish workflow using git (and may sometimes make sense to, >> although I am struggling to thing of such a time). > > I've been using Hg myself for the 'DVCS' style of working. This allows me to > publish my own ports of things which others can follow, but from which I can > push things back to the original project as required. I'm still not convinced > that the 'production' branches such as PHP5.3 can be run without some element > of > management, although of cause a release will still be packaged as a tarball > set > and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10 > ... as I require it direct from the repo but some of the projects I am working > with have now lost the 'master' codebase simply because groups of developers > are > now doing their own thing. The overall flexibility of DVCS still needs a > mindset > of maintaining a code base that follows the master route plan? Which may well > be > a more 'svnish' way of working when testing and committing production ready > code?
I use Hg at work, and while it's a pretty fine DVCS, it's more in line with SVN's mindset than git's in parts. Namely, Hg focuses, afaict, on making it easy to move the commit history forward in time by abstracting over the manipulation of the DAG. Git focuses on manipulation of the DAG -- the line between locally-visible and remotely-visible stuff is more blurry in Hg than in git, and it feels like you're using the tool in unintended ways when you clarify that line in ways Hg doesn't expect. That's not necessarily a bad thing or whatnot, just a thing. > The question I think that needs to be asked is 'should experimental > development > branches exist in the master code base?' all very easy to do with DVCS, but is > it practical. > Does it not make sense to clone the experimental work from another > source, and keep the main codebase tidy with just proven pushes that follow > the > production path. There is nothing actually stopping someone producing their > own > private branch and sharing that while it is being developed, just pushing the > results back to the relevant master branch when development work has been > completed? If the experimental branches are long(er)-lived and worked on or of interest to people who'd be checking out master, sure. There's definitely a balancing act -- you don't want 500 experimental branches laying around yer main repo, but that probably won't happen, in no small part because when you merge the experimental branch in to a master release you can just delete it. The commits won't be lost, but it won't be showing up in `git branch -ar` or whatnot -- the branch is just a pointer to a node in the DAG to git. There isn't the concept of "permanent always-stick-around-branch" like in Hg, unless you decide to make it so. For a good example of "hey keep these relevant branches around on master", take a look at https://github.com/symfony/symfony . There's a few branches sitting around on their main repo at any point in time -- the master, development branch, maybe some other feature, whatever. Like you mention, people interested in a particular niche of the framework are pulling from branches on each others git repositories, and there are a ridiculous amount of branches in the ecosystem, see https://github.com/symfony/symfony/network . For a bad example, look at the git mirrors of emacs (at least the last time I looked at them). Yeah, there's reasons for it there, but the point is that having too many of them produces noise. Which is true. I don't think there are any hard and fast rules here, but at least git makes it easy to change things up if they lean too far in either direction. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
