Regarding usability on windows, we have the following setup at work: msysgit KDiff3 Git Extensions Git Source Control Provider
The last two tools integrate with visual studio, and provide a very nice UI. Also, msysgit seems quite mature; reasonably fast and no issues. I had to set this up because I was facing a developer mutiny over using the Git command. Cheers! Jorge On Wed, Nov 3, 2010 at 9:18 AM, Ayende Rahien <[email protected]> wrote: > inline > > On Wed, Nov 3, 2010 at 3:10 PM, Frans Bouma <[email protected]> wrote: >> >> > Frans, >> > Git is more popular than hg. And we aren't considering centralized SCM >> >> you already use centralized scm, and IMHO for a reason: there has >> to >> be a central trunk so people who want to pull the latest code which has >> the >> commits of the _team_ is stored centrally. >> > > um, not. > Look at how RavenDB is handled, there are plenty of forks, but the mater > fork is github.com/ravendb/ravendb > There is a HUGE difference between having a central location and centralized > SCM. > >> >> Local dev might be easier, but you still need to create a central >> trunk. >> IMHO opting for git over mercurial is stupid as mercurial works >> better on windows. >> > > I am using Git on Windows for a while now, absolutely no issues. > I would classify this as nonsense based on very out of date info. > >> >> > And yes, there is a HUGE difference between sending a patch and sending >> > a >> > pull request. >> > >> > a) it is significantly easier to handle a pull request, because it is a >> > single command, rather than a set of operations >> >> creating a patch with svn is easy too. I always find it funny to >> read how svn seems to suck these days while it was the best thing since >> sliced bread a couple of years ago. Sourcecontrol isn't rocket science and >> a >> big part of it is management: who does what. > > Frans, > If you send me a patch, I need to: > a) download the patch > b) browse to the patch > c) select where to apply it > d) WAIT until SVN fetches old version of files > e) resolve conflicts > With git, I need: > git pull your-repos master > And resolve any conflicts if needed to (usually not). > The difference in time & effort is huge. > >> >> > b) it allows you to have your own fork and easily merge future changes >> >> svn can do that too, but perhaps you simply hate it now so much, > > Huh? > Frans, if you can, please create a fork of NHibernate using SVN. > Then keep track of changes as they come along. > >> >> don't know. Just setup a .cmd file with a simple svn command which merges >> the trunk with your branch locally. Solve some conflicts (and don't come >> to >> me git solves all conflicts magically, svn 1.5 most of the time has no >> conflicts either, or are easy to solve.), commit, done. >> > > You are talking about svk. I tried that, I was decidedly unimpressed > >> >> and as you need a central trunk anyway, there's 1 person who >> decides >> which patches will be merged into the trunk, so things hardly change >> there. > > Nope, all committers have access to the central repo > >> >> Only development locally might change, but is that really a problem today? > > Yes. > Example from recent past, I had a regression show up, I needed to figure out > exactly where. > The PAIN of going through the log and revision on SVN was acute. > >> >> IMHO the problem of writing code is far more complex than dealing with >> some >> scm problem, as ALL have problems and sucky things. >> >> > c) it means that Joe can pull from you, not just from the master feed >> >> and when is this an advantage? > > Well, for example, you might have fixed something that still haven't made it > to the main repo. >> >> You're developing a framework, where >> potentially a lot of code relies on other code in that same framework, >> (and >> in NH it's even worse, almost all namespaces touch other namespaces >> directly >> or indirectly), > > Please don't bring that old nonsense up again. > >> >> so pulling code outside the main trunk to work on IMHO >> >> creates a lot of different 'realities' which are even harder to test than >> with a trunk alone. > > RavenDB is a great example of how it works. > >> >> tl;dr: scm doesn't solve problems which have nothing to do with >> scm. >> >> >> FB >> >> > >> > >> > >> > On Wed, Nov 3, 2010 at 12:54 PM, Frans Bouma <[email protected]> wrote: >> > >> > >> > > I actually do have a problem with hg. I think that Git is: >> > > a) more popular >> > >> > >> > than what, subversion? Perforce? CVS? >> > >> > >> > > b) GitHub has tremendous pull in terms of encouraging >> > contributions. >> > > c) I saw a huge spike in the amount of people contributing once >> > I >> > moved to >> > > github. >> > >> > >> > I have a hard time believing that the scc system used is of >> > any >> > relevance whether a developer is capable of contributing any code. >> > I >> > mean: >> > it's not as if someone who changes some code in his own branch is >> > suddenly >> > able to commit those changes as well: the change has to be >> > reviewed, >> > tested, >> > agreed upon and then it's committed. A svn patch is just as simple >> > for that >> > than any other patch. >> > >> > I don't deny what you saw on ravendb stuff, I just find it >> > a >> > 'coincidence' rather than a correlated event. >> > >> > FB >> > >> > >> > > >> > > >> > > On Wed, Nov 3, 2010 at 12:31 PM, Fabio Maulo >> <[email protected]> >> > wrote: >> > > >> > > >> > > And move the code in CodePlex... >> > > >> > > >> > > -- >> > > Fabio Maulo >> > > >> > > >> > > El 02/11/2010, a las 16:38, Jorge <[email protected]> >> > escribió: >> > > >> > > >> > > > Hello there, >> > > > >> > > > I am in the process of downloading the code via SVN, and >> it >> > is >> > > taking >> > > > a very long time. >> > > > >> > > > Can someone please enable Git repo in sourceforge, or >> > better yet, >> > > move >> > > > code to Github? >> > > > >> > > > Respectfully yours, >> > > > Jorge >> > > >> > > >> > >> > >> > >> > >> >> > >
