El dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió: > Dirk-Willem van Gulik wrote: > > Ross Gardler wrote: > > > I understand that GiT can be used locally as a layer on top of SVN. > > > I believe this gives you most of the perceived benefits of GiT > > > locally without the need for a project itself to switch to GiT. > > The issue isn't git as an SVN client. No one (as far as I know) cares what > SVN client(s) you use, so long as they don't abuse our SVN server. >
I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. I agree that exporting svn to git/bazaar/mercurial, etc is a way forward, but it will cause strain to the svn server, for sure. As seen elsewhere, Jason took this path, and I'm actually using this technique in a number of places, both with git-svn and bzr-svn. I will keep reporting. > > I am a bit lost here as well -- what does GiT add to the processes/ > > workflows common in the ASF ? > I already answered to this one in the thread. - faster commits, branch switching, pulls and pushs - merges, good and persistent merges - offline work, offline history diffs - rebasing is not such a "feature", but it can be useful sometimes - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing I hope helping each and every developer/contributor counts as helping the ASF. > > One of the great things about GiT is that you can can have lots of > > parallel and non-linear merges (every developer their own branch; > > > However in the ASF most groups work roughly along fairly linear lines; > > with 'one' or just a 'few' points at which a patch is accepted - and > > essentially few, or just one, merge point (or a single line of merge > > points when backported). Rarely do we merge multiple 'HEAD's. > huh? every "vendor" keeping patches against apache repositories is merging often. I don't follow your reasoning, anybody keeping patches is merging repeatedly against a moving HEAD (for active projects). In my view, every developer that maintains patches is in effect having a *private, unpublished* branch. With git and a setup like the one in kernel.org, all those patches are suddenly public, visible. Think about it. > And most importantly, we want our development to be visible to the > Community, not done in private and committed when finished. Developers can > always make more or less transient branches to work on code, still in public > view, and merge back to shared locations. The key point here that I believe > you, I, William and others are all making isn't about technology, it is > about practice. > The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Personal repositories can be kept in public, you just can look into the different branches in http://git.kernel.org/?p=linux/kernel to see how a number of those are updated a lot. Turning your "key poing" upside down: "We should not try to impose our practices using a technological tool, specially when doing so impairs development." > Now, if there is an SCM that substantially improves the ASF's ability to > perform *our* practices, that is a separate discussion item. > I'm quite sure currently any one of git, bazaar, mercurial or even darcs would improve our practices. Just to make sure, my view of the discussion: people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices I don't think the discussion is, and never was presented as: evil revolutionaries wanting to break the practices by introduction of sneaky "solipsistic" tools. I don't think git will break ASF practices more than keeping quilt patches, or several repositories, to survive "svn up" without nasty conflicts. Regards Santiago > --- Noel > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
