That's an excellent point I'd (obviously) not considered. For git there are several that I am aware of (not intended to be a comprehensive list, just some examples)... * http://code.google.com/p/gitextensions/ * http://gitscc.codeplex.com/
For Hg, there's this one, and probably more.... * http://visualhg.codeplex.com/ For Windows Shell integration, there is also the Tortoise* line of 'products' for both Git and Hg (though neither of these integrate w VS per se, they do offer a lower barrier-to-entry). I've used gitextensions myself with great success under git and VS2010 but have no experience with Hg addins (either the one listed or otherwise). Does anyone have any pos. or neg. experiences to offer in re: the VS tooling concerns? Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Wed, Aug 3, 2011 at 6:27 PM, John Davidson <[email protected]> wrote: > I would like to add integration with Visual Studio as a consideration > point. Proper integration will reduce the friction and the need to depend > upon a separate interface for most common functionality. > > John Davidson > > > On Wed, Aug 3, 2011 at 5:46 PM, Stephen Bohlen <[email protected]> wrote: > >> IMO the research, suggestions, and confirmations that this thread has >> already elicited from several in the community do count as valuable >> action/progress so I think we're proceeding not all that poorly thus far. >> Once we reach consensus on exactly what we're going to do, hopefully we >> should be able to do it in pretty short order. >> >> Of course, my suggestion of 8/15 was just a target for us and if we miss >> because we are too careful in making the right choice, I'd prefer to err on >> the side of being slower and more certain that we're making the right >> selection. That said, your sense of urgency is welcomed (and of course its >> the other reason I threw out the date: nothing motivates decision-making >> quite like a looming deadline, even if its a completely made-up one <g>). >> >> I think the way to proceed is to divide the choices into several broad >> categories (each somewhat independent of each other) and try to reach >> agreement on each of them (leading to subsequent action). >> >> Categories: >> * issue tracking platform >> * project homepage location (e.g., what and where is "NHCentral?") >> * source control platform >> >> >> ** Issue Tracking Platform ** >> >> It seems that we are tending towards the decision to remain with (the new) >> hosted JIRA for issue tracking and that we believe that our hosted platform >> has already-available integration modules for either git or hg (almost >> certainly the two candidates for DVCS selection). Are there any objections >> to the choice to remain with JIRA for issue tracking (assuming it can be >> well-integrated to link issues to commits in whatever DVCS we select)? >> >> ** Project Homepage location ** >> >> One of the major problems I have seen with OSS projects that move around >> from platform to platform (even just once!) is that the project's sense of >> self gets badly diluted. Old, outdated, abandoned homepages with >> incorrect/superseded info, download links, and more make it frustrating for >> adopters to find what they are looking for, etc. We have ALREADY >> experienced a very tiny part of this phenomenon in the nhibernate forums on >> hibernate.org where sometimes people STILL post issues that (obviously) >> go unanswered, etc. IMO its very important as part of any move that the >> existing project pages, download links, etc. are removed and replaced NOT >> with new new links but with a single link to a single authoritative project >> space that contains all the info needed to get started with either consuming >> or contributing to NHibernate. >> >> I would propose that we rely heavily on NHForge.org for this and adjust >> the SF page(s) and links, any new readme files, etc. in any DVCS we select, >> etc. to offer only a single link to a starting page on NHForge.org that >> contains all info about the project (link to issue tracker, link to >> downloads, link to ref docs, etc.). This leaves us with only a single >> authoritative place to ensure all links, etc. are correct/updated. >> >> What are people's thoughts on the viability of this suggestion? >> >> ** Source Control Platform ** >> >> In past discussions, this has become a choice between git and hg. Its >> reasonable to assume that this is still the decision-point that remains to >> resolve in this area. If there is a third candidate we want to consider, >> someone reading this thread please point it out. It also seems reasonable >> to conclude that this also boils down to a choice between github or >> bitbucket rather than other choices for ecosystems that offer either or both >> git and/or hg (e.g., hg on codeplex or git on googlecode, etc.). If this >> assumption is incorrect, someone please point that out as well. >> >> Comparing hg vs. git on their technical merits doesn't seem (to me at >> least) to yield enough of a difference in any critical must-have feature to >> be itself a deciding factor. If anyone feels otherwise, please let us know >> ("we must choose XYZ because its the only one of the two that has feature >> ABC that we really need in order for this project to be a success!"). >> >> As this choice between git/github and hg/bitbucket has always been >> presented to me, the following seem to be the arguments in favor of the >> hg/bitbucket choice: >> * hg installs and runs better/simpler on Windows >> * this lowers the barrier-to-entry of anyone getting the code and >> submitting patches (well, forks in this case, but you get the point <g>) >> >> The frequent arguments advanced in favor of git/github seem to be: >> * the github ecosystem (e.g., "social coding") is its winning feature >> * this lowers the barrier-to-entry of anyone getting the code and >> submitting patches (again, forks!) >> >> Are their other arguments for or against hg or git that we need to >> consider? I would like to get as many of them listed here so that we have >> as much info as possible upon which to try to reach a consensus. We're >> looking for actual pros and cons for this decision, NOT just "+1 for github, >> it rocks!" but an actual *reason* one or the other might "rock". >> >> All opinions welcomed (and yes, I realize this is a rehash of other >> threads on this very topic, but lets try to get them all in one place one >> last time to facilitate making a final choice on this matter). >> >> Thanks, everyone --! >> >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> On Wed, Aug 3, 2011 at 11:09 AM, Patrick Earl <[email protected]> wrote: >> >>> I'll wait to do anything then. How should we proceed with reaching a >>> decision? I feel a definite sense of urgency since the deadline has >>> been selected and we haven't started the work yet. >>> >>> Patrick Earl >>> >>> On Wed, Aug 3, 2011 at 7:15 AM, Stephen Bohlen <[email protected]> >>> wrote: >>> > It should be noted that while all this research is extremely valuable >>> and >>> > quite helpful, no actual decision has been reached re: what changes >>> we're >>> > actually going to be making at this early point in the process :) >>> > >>> > -Steve B. >>> > ________________________________ >>> > From: Mauricio Scheffer <[email protected]> >>> > Sender: [email protected] >>> > Date: Wed, 3 Aug 2011 09:52:37 -0300 >>> > To: <[email protected]> >>> > ReplyTo: [email protected] >>> > Subject: Re: [nhibernate-development] Re: DCVS >>> > Yes, I can pull any last minute commits. >>> > You can store the filter-branch script in a gist, no need for a full >>> > repository... >>> > >>> > -- >>> > Mauricio >>> > >>> > >>> > On Wed, Aug 3, 2011 at 2:30 AM, Patrick Earl <[email protected]> wrote: >>> >> >>> >> This is great advice. Thanks Mauricio. I found an article that gives >>> >> some tips on how to accomplish the tag thing you mentioned, as well as >>> >> some other clean-ups. >>> >> >>> >> http://thomasrast.ch/git/git-svn-conversion.html >>> >> >>> >> Based on what you've said, it sounds like we need to do at least a >>> >> couple things. >>> >> >>> >> 1. Have committers sign up for github accounts so the history can be >>> >> mapped nicely. Unless more mass user actions come up, it seems like a >>> >> good idea to start a separate urgent thread to have committers provide >>> >> their details for the conversion. >>> >> >>> >> 2. Write a script that will convert your repository appropriately. >>> >> Is it safe to assume that you'll be able to pull any last minute >>> >> changes from SVN into your repo? I propose that we set up a GIT >>> >> repository to store the script to be used for the conversion. We can >>> >> then refine it and learn a bit along the way. >>> >> >>> >> If nobody else does it, I'll do these things tomorrow to get the ball >>> >> rolling. >>> >> >>> >> Patrick Earl >>> >> >>> >> On Tue, Aug 2, 2011 at 1:46 PM, Mauricio Scheffer >>> >> <[email protected]> wrote: >>> >> > It's not really *required* to do this mapping, it's only very >>> convenient >>> >> > so >>> >> > that github can create links from every commit to the committer >>> account, >>> >> > and >>> >> > also for future statistics. >>> >> > >>> >> > Another thing to decide is what to do about tags. Git-svn models >>> tags as >>> >> > separate commits (because each svn tag creates a new revision), but >>> >> > that's >>> >> > not how git usually handles tags. You could go over each tag and >>> >> > redefine >>> >> > it, e.g. instead of the 3.1.0GA tag being here : >>> >> > >>> >> > >>> https://github.com/mausch/NHibernate/commit/a971c20f9be652a59bc467d8e61bbad2f2928ef3 >>> >> > as a separate commit, it would be here: >>> >> > >>> >> > >>> https://github.com/mausch/NHibernate/commit/3c2d5fdbeeebc87f089bac2306792b8ef4459a81 >>> >> > which is the commit before that. Clone the repository and use gitk >>> to >>> >> > better >>> >> > visualize this. >>> >> > Also, tags in git can be lightweight, annotated or even >>> >> > cryptographically >>> >> > signed if you're really paranoid about people redistributing code >>> with >>> >> > edited tags. >>> >> > >>> >> > -- >>> >> > Mauricio >>> >> > >>> >> > >>> >> > On Tue, Aug 2, 2011 at 4:27 PM, Mauricio Scheffer >>> >> > <[email protected]> wrote: >>> >> >> >>> >> >> Right now, on my github mirror all committers have names >>> autogenerated >>> >> >> by >>> >> >> git-svn. For example: "patearl >>> >> >> <patearl@d2eaab8a-a80d-0410-be94-99ecdb4ea5df>". >>> >> >> Git filter-branch should be used to change all commits and map >>> those >>> >> >> autogenerated names to the actual github accounts (e.g. the email >>> used >>> >> >> for >>> >> >> https://github.com/patearl ), otherwise all commits are pretty >>> much >>> >> >> anonymous, detached from their actual owners. >>> >> >> Here's a sample script that does this for a single user: >>> >> >> >>> http://progit.org/book/ch6-4.html#changing_email_addresses_globally >>> >> >> The filter-branch docs also has some examples about this: >>> >> >> >>> http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html >>> >> >> >>> >> >> Cheers, >>> >> >> Mauricio >>> >> >> >>> >> >> >>> >> >> On Tue, Aug 2, 2011 at 4:00 PM, Patrick Earl <[email protected]> >>> wrote: >>> >> >>> >>> >> >>> On Tue, Aug 2, 2011 at 10:35 AM, Mauricio Scheffer >>> >> >>> <[email protected]> wrote: >>> >> >>> > If NHibernate decides to move to git, you might be interested in >>> my >>> >> >>> > github mirror: https://github.com/mausch/NHibernate , which >>> contains >>> >> >>> > of course the whole history, is up to date, and has all tags and >>> >> >>> > branches. >>> >> >>> >>> >> >>> That sounds great Mauricio. Thanks for the heads up. >>> >> >>> >>> >> >>> > All that would be needed to complete the migration is mapping >>> the >>> >> >>> > committers to their proper github accounts (which isn't hard, >>> just >>> >> >>> > some filter-branches, doesn't take too long). So the slowest >>> part >>> >> >>> > (migrating the actual commits from SVN to git) is already done. >>> >> >>> >>> >> >>> Can you suggest what you mean here to do the mapping? It sounds >>> like >>> >> >>> you have a very clear idea of what needs to be done. >>> >> >>> >>> >> >>> > Of course, tooling support is a separate issue. I don't know >>> what >>> >> >>> > tools NHibernate currently uses that depend on SVN (could be >>> nant >>> >> >>> > for >>> >> >>> > tagging, TeamCity, JIRA integration, ...) >>> >> >>> >>> >> >>> TeamCity has built-in GIT support, so that shouldn't be a problem. >>> >> >>> The releases haven't even been using the SVN revision for the >>> version >>> >> >>> number, so we're more or less okay on that front. We don't have >>> JIRA >>> >> >>> set up with any VCS integration right now, so integrating would >>> only >>> >> >>> be an improvement. Do we have some sort of script or anything to >>> run >>> >> >>> tagging on release? The release process is a mystery to me >>> >> >>> personally. :) >>> >> >>> >>> >> >>> Patrick Earl >>> >> >> >>> >> > >>> >> > >>> > >>> > >>> >> >> >
