I have switched all my OSS project and all commercial projects where I am directly involved to Hg. In OSS I saw some personal branch with modifications but without neither an open issue nor a pull request.... Only a *fact* to add to the discussion. The day that I'll do the same I'm pretty sure that somebody will have something to say... and I'm very closer to do it with one or two OSS prj.
-- Fabio Maulo El 04/11/2010, a las 11:31, "Wenig, Stefan" <[email protected]> escribió: > Hey Frans, > > Let me try to put it in a way that might makes more sense to you. If it > doesn't, I agree we should just stop here. > > DVCS just gives you more options. If you use it on a tightly managed project, > you might want a few extra guidelines to cover the situations that might > arise from those options. I think that's what your discussion basically boils > down to. And I agree. For instance, a project that has mandatory copyright > assignments won't necessarily like people to pull and push their changes from > everywhere. > > But I don't believe that the NH team is too strict with patches and > guidelines. A committer applies a patch and takes responsibility, period. > Whether this person would merge pulls and their own edits or not is up to > them. > > It's not true that then after all it's no different in DVCS from simple > patches. It's more similar to feature branches: working on a patch would give > you zero versioning before you're done, and the guy creating that patch would > have a hard time continuously applying that patch privately to new > trunk/branch version checkouts until it gets accepted. > With DVCS, you get this without any management overhead for creating the > feature branch. Also, merging is much easier since changes are tracked per > repository, not per file. > > So while we, just like you, didn't (yet) switch our own stuff to DVCS, I > think that it would probably be a very good choice for NH. > > Cheers, > Stefan > >> -----Original Message----- >> From: [email protected] [mailto:nhibernate- >> [email protected]] On Behalf Of Frans Bouma >> Sent: Thursday, November 04, 2010 1:01 PM >> To: [email protected] >> Subject: RE: [nhibernate-development] Re: Turn on Git support in >> sourceforge ? >> >>> On Thu, Nov 4, 2010 at 1:07 PM, Frans Bouma <[email protected]> wrote: >>> > You are confusing theoretical problems with actual problems. >>> I don't think I do. >>> >>> You keep bringing up potential problems, and you ignore me when I >> tell you >>> that they don't occur or rarely occur in practice >> >> Time will tell, Oren. Sourcecode management, or better, what's >> the >> 'real current version' isn't a problem which is related to the used >> SCM. >> >>> > Again, RavenDB as a case in point. I got 27 people contributing >>> code, all >>> of >>> > them using the Pull Request model. >>> >>> all 27 write code to the main trunk, or did they provide a >> patch of >>> some sort? >>> >>> All of them work on their own repo. >>> They send me a pull request, and I pull their changes to the main >> repo, >>> after reviewing / testing / modifying the code. >> >> With a DSCM you pull changes the user has pulled from others as >> well, you need to avoid those, but if the user has to do that for you, >> what's the difference with creating a patch in svn for the main trunk? >> >> Also, who on the main committers list is going to review code >> pulled >> from others if it matches the rest of the code of NH? So it matches a >> codeing standard, doesn't introduce clones, doesn't do things already >> there, >> has no documentation etc. >> >>> This is a huge difference. I'm not saying it doesn't work, I'm >>> saying you need a strict policy in place who is going to review >> the >> code >>> added to the main trunk. >>> >>> There is absolutely no difference than with patches. >>> Only committers get to touch the main repo. >> >> sure, it was about reviewing changes from others. If there's 1 >> trunk, everyone has patches for the trunk, with a DSCM, a main >> committer can >> pull with a pull request the changes of others pulled into that branch, >> which would have been a separate trunk patch (IMHO) in svn/central >> trunk. >> >>> with patches provided which have to be applied to >>> the main trunk by a main committer, this is automatic. >>> >>> Care to explain how DVCS will allow you to make any change to NH main >> repo >>> without explicit action by one of the committers? >> >> If I pull changes from John and John isn't a main committer, and >> you >> pull changes from my branch, you get John's changes as well. You then >> have >> to review those as well. That's something you have to deal with. If >> John's a >> crappy coder and I don't give a hoot, you have to decide if John's >> stuff is >> necessary for my changes. As you pull from me, I'm responsible for the >> patch, as it's all in my patch, but as I don't care (example) it's >> harder to >> apply my patch to the main trunk because of John's work. So it comes >> down >> to: accept everything, thus also john's code, because my tests worked >> (but >> john's crap code is in there too) vs. reject everything and tell me to >> clean >> it up first vs. you do the cleaning. >> >> If I use a central trunk repo, John's changes wouldn't have been >> in >> my changes, as I change on the trunk's repo and send a patch. John's >> patch, >> as he's a crapcoder, was rejected (or never even sent), less work for >> the >> maintainer who looks at my patch. >> >> No offense to any John ;). >> >> IMHO the central trunk works better for this, because it's easier >> to >> apply patches to a main trunk for the main committers: John's drivel >> was >> filtered out without looking at my patch. Throwing out my patch because >> John's goo was in there too is also easy, but that halts progress. >> >>> With pulling code all >>> over the place and auto-commits of changes, this is hardly the >> case: >>> you >>> then actively have to review every change you commit. >>> >>> Frans, >>> I think that you miss a crucial part of how DVCS work. It is very >> rare to >>> pull directly from someone else to the main repo. >>> What usually happen is that I pull from someone's repo to my local >> one, >>> verify that things work, then push to the main repo. >> >> I'm aware how it works Oren, the concept of feature branching >> isn't >> something unique to DSCM. I wasn't talking about 'if it works', I was >> talking about the quality of the code being pushed to the main repo. >> >>> > I had a single instance of having to prune someone else's >> changes >> (which is >>> > what I meant by not happening very often). >>> >>> Like I said, I'm likely very focused on code quality and >> that >> it >>> obeys strict guidelines, and will throw out 90% of code provided >> by >> others, >>> while others are more relaxed. It's however not even the case >> that >> there IS >>> a guideline for NH's sourcecode (we're not talking ravendb, but >> NH's >> code, >>> which is much bigger and most of it is ported code, so not >> designed >> by the >>> main committers). >>> >>> To be perfectly frank, it sounds like you don't have any experience >> with >>> DVCS, or that you never used in in DVCS like fashion. >> >> oh haven't I? Next time you're going to claim I haven't used >> feature >> branching or a decent SCM or how to manage sourcecode across versions >> ;) >> >> But anyway, I'll leave it at this, this thread isn't going >> anywhere >> anyway. >> >> FB >> >>> >>> >>> >>> Anyway, as I feel I'm barking to a tree and it's >> apparently >>> not a >>> problem, why should I even care. >>> >>> >>> FB >>> >>> > >>> > >>> > On Thu, Nov 4, 2010 at 12:46 PM, Frans Bouma <[email protected]> >> wrote: >>> > >>> > >>> > > a) I can pull specific commits >>> > >>> > >>> > yeah, like that's gonna work. Changes A, B, C and >> D. >>> You can >>> > pull >>> > 'C' but you need A and B then as well. >>> > >>> > >>> > > b) I am going to reject any changes that I don't like. >>> > > c) I am going to review any code that I am pulling. >>> > >>> > >>> > and how many of the 'committers' will do so? >>> > >>> > >>> > > d) This scenario just doesn't occur all that often. >>> > >>> > >>> > that contradicts your claim that with github >> things >>> will >>> > flourish: >>> > as there aren't suddenly a large group of new master feed >>> committers, >>> > the >>> > new stuff comes from people not committing to the main >> trunk >>> but to >>> > their >>> > own branches which are pulled from. >>> > >>> > >>> > > e) Even if it does, I can ask you to create a specific >>> branch just >>> > with >>> > your >>> > > changes. >>> > >>> > >>> > as this increases headaches, I am sure no-one will >> do >>> this >>> > voluntairily. You then have to keep track which local >> copy >>> contains >>> > which >>> > changes. It's not a small project, the sourcecode is >> huge, >>> and the # >>> > of >>> > tests to keep track of therefore is huge too. you can't >>> simply test >>> > things >>> > in a small clean-room, changes sometimes affect things >> all >>> over the >>> > place. >>> > >>> > >>> > FB >>> > >>> > > >>> > > >>> > > On Thu, Nov 4, 2010 at 12:14 PM, Frans Bouma >> <[email protected]> >>> wrote: >>> > > >>> > > >>> > > > Frans, >>> > > > There are gate keepers, and they are >> responsible >>> for doing >>> > that. >>> > > > I, for example, have about 50% chance of >> telling >>> the user >>> > to fix >>> > > his code >>> > > > and 50% to fix the code myself. >>> > > > Remember, we are still talking about only >>> committers being >>> > able to >>> > > merge >>> > > > code to the main repo. >>> > > >>> > > >>> > > sure, but if you say, pull from my >> repository >>> (as you >>> > referred >>> > > to >>> > > that as a plus for git), you get my changes as >> well. >>> If you >>> > commit >>> > > your >>> > > work, your code contains my changes as well, and >> thus >>> you >>> > have to >>> > > verify my >>> > > code as well. This can add up if I pulled from >>> someone out >>> > there and >>> > > didn't >>> > > verify the code. >>> > > >>> > > FB >>> > > >>> > > >>> > > > >>> > > > >>> > > > On Thu, Nov 4, 2010 at 11:22 AM, Frans Bouma >>> <[email protected]> >>> > wrote: >>> > > > >>> > > > >>> > > > What I wondered, and what hasn't been >> debated >>> (at >>> > least not >>> > > this >>> > > > 'round'), >>> > > > is: how is code reviewing done? My >> experience >>> with >>> > being an >>> > > OSS >>> > > > maintainer >>> > > > is that it's likely people give you >> 'patches' >>> which >>> > are not >>> > > matching >>> > > > how >>> > > > things should be coded, are sometimes of >> poor >>> quality >>> > or cut >>> > > corners >>> > > > and you >>> > > > have to adjust them a bit to avoid a big >> pile >>> of >>> > crapcode. >>> > > Maybe I'm >>> > > > too >>> > > > anal when it comes to code quality but as >>> soon as >>> > people are >>> > > able to >>> > > > easily >>> > > > add patches to the trunk without review, >> it's >>> hard >>> to >>> > fix >>> > > that later >>> > > > on. >>> > > > E.g. if a rule about 'document what you >> add' >>> is in >>> > place, >>> > how >>> > > is >>> > > > checked >>> > > > that a committer indeed documented what's >>> been >>> added? >>> > > > >>> > > > With a distributed system, it's harder to >>> verify >>> what >>> > is >>> > > coming from >>> > > > where, >>> > > > if people are updating from non-master >>> repositories: >>> > the >>> > > person who >>> > > > commits >>> > > > to the master has more to commit in that >> case >>> than >>> > his own >>> > > changes: >>> > > > also the >>> > > > changes he pulled from a different >> source. >>> How is >>> > verified >>> > > those are >>> > > > in the >>> > > > same quality? >>> > > > >>> > > > Or is there just 1 rule: if the tests run >>> 'it's good >>> > enough' >>> > > ? >>> > > > >>> > > > FB >>> > > > >>> > > > >>> > > > > +1 for github >>> > > > > >>> > > > > github is much better option than >>> codeplex+hg (in >>> > my >>> > > opinion) >>> > > > > >>> > > > > The intregated support and management >> of >>> pull >>> > requests and >>> > > the >>> > > > whole >>> > > > > community aspect around the source code >>> > repositories is a >>> > > real >>> > > > boost to >>> > > > > contribution and easy managment. If you >>> really >>> > prefer >>> > > mercurial >>> > > > than go >>> > > > with >>> > > > > bitbucket and you get some of the good >> this >>> github >>> > brings. >>> > > > > >>> > > > > From a pure capability and tooling >>> perspective I >>> > think >>> > > Mercurial >>> > > is >>> > > > a >>> > > > little >>> > > > > better (at least on windows) but I >> think >>> that is >>> > > compensated by >>> > > the >>> > > > how >>> > > > > great github. >>> > > > > >>> > > > > just my 2 cents. >>> > > > > /Torkel >>> > > > > >>> > > > > On 3 Nov, 13:36, Fabio Maulo >>> <[email protected]> >>> > wrote: >>> > > > > > sorry NUnit is in launchpad. >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > On Wed, Nov 3, 2010 at 9:32 AM, Fabio >>> Maulo >>> > > > <[email protected]> >>> > > > wrote: >>> > > > > > > Moq svn (Google code) >>> > > > > > > NServiceBus svn + git (Source forge >> + >>> GitHub) >>> > <== >>> > > Official in >>> > > > SVN >>> > > > > > > Rhino.ServiceBus git (GitHub) >> uNhAddIns >>> Hg >>> > (Google >>> > > code) >>> > > > > > > SharpTestsEx Hg (Code Plex) ConfORM >> Hg >>> (Google >>> > Code) >>> > > NUnit svn >>> > > > > > > (SourceForge) Castle git (GitHub) >>> Spring svn >>> > (custom) >>> > > > NHibernate svn >>> > > > > > > (SourceForge) NHibernate.Validator >> svn >>> > (SourceForge) >>> > > > > > > NHibernate.Spatial svn >> (SourceForge) >>> > NHibernate.Search >>> > > svn >>> > > > > > > (SourceForge) NewtonJson svn >> (CodePlex) >>> Log4Net >>> > svn >>> > > (Apache) >>> > > > Lucene >>> > > > > > > svn (Apache) Re-Linq svn (custom + >>> CodePlex >>> > only for >>> > > deploy) >>> > > > ANTLR >>> > > > > > > svn (Custom) SharpMap svn (Code >> Plex) >>> > > > > > >>> > > > > > > On Wed, Nov 3, 2010 at 9:11 AM, >> Ayende >>> Rahien >>> > > > <[email protected]> >>> > > > wrote: >>> > > > > > >>> > > > > > >> I mean popular in the sense that >> out >>> of the >>> > .NET >>> > > projects >>> > > that >>> > > > I >>> > > > > > >> follow that uses DVCS, most use >> Git. >>> > > > > > >>> > > > > > >> On Wed, Nov 3, 2010 at 1:54 PM, >> Fabio >>> Maulo >>> > > > <[email protected]> >>> > > > > wrote: >>> > > > > > >>> > > > > > >>> I know lot of OSS using SVN more >> than >>> Git... >>> > btw.. >>> > > > > > >>> Mercurial is supported by >> Bitbucket, >>> Google >>> > Code, >>> > > > SourceForge, >>> > > > > > >>> CodePlex Please give me a more >>> detailed >>> > definition >>> > of >>> > > > "popular" >>> > > > > > >>> since its translation in Italian >> and >>> in >>> > Spanish can >>> > > be >>> > > > interpreted >>> > > > > > >>> as "not used only by elite". >>> > > > > > >>> > > > > > >>> On Wed, Nov 3, 2010 at 8:42 AM, >>> Ayende >>> Rahien >>> > > > <[email protected]> >>> > > > > wrote: >>> > > > > > >>> > > > > > >>>> Diego, >>> > > > > > >>>> I know of a LOT of OSS projects >>> which are >>> > using Git >>> > > I know >>> > > > of >>> > > > > > >>>> very few using HG. >>> > > > > > >>> > > > > > >>>> On Wed, Nov 3, 2010 at 1:37 PM, >>> Diego >>> > Mijelshon >>> > > > > > >>>> <[email protected] >>> > > > > > >>>> > wrote: >>> > > > > > >>> > > > > > >>>>> Oren, >>> > > > > > >>> > > > > > >>>>> What stats do you use to say >> Git >> is >>> more >>> > popular? >>> > > > > > >>>>> I think they both have lots of >>> followers. >>> > > > > > >>> > > > > > >>>>> I'm slightly biased towards HG, >>> because it >>> > has an >>> > > easier >>> > > > > > >>>>> learning curve and it doesn't >> have >>> the >>> > "non-native" >>> > > feel >>> > > of >>> > > > Git on >>> > > > > Windows. >>> > > > > > >>>>> Regarding the specific points >> you >>> > mentioned: >>> > aren't >>> > > those >>> > > > just >>> > > > > > >>>>> Github features whose current >>> > implementation you >>> > > like >>> > > > instead of >>> > > > > > >>>>> Hg/Git differences? >>> > > > > > >>> > > > > > >>>>> In any case, here's my 2c >> regarding >>> source: >>> > > > > > >>> > > > > > >>>>> - There seems to be a >> consensus >>> to move >>> > to a >>> > > DVCS. >>> > > > Nobody >>> > > > > > >>>>> wants to >>> > > > > > >>>>> stay with SVN >>> > > > > > >>>>> - As others said, after the >>> release >>> > might be a >>> > > good >>> > > time >>> > > > to >>> > > > > > >>>>> do the >>> > > > > > >>>>> move >>> > > > > > >>>>> - IMO, the decision should >> be >>> done >>> first >>> > by the >>> > > > committers >>> > > > > > >>>>> and, if >>> > > > > > >>>>> there isn't a clear winner, >> by >>> the >>> > contributors. >>> > > How >>> > > > about a >>> > > > > poll? >>> > > > > > >>> > > > > > >>>>> And regarding the site (in no >>> particular >>> > order): >>> > > > > > >>> > > > > > >>>>> - I've said it before: the >>> current >>> state >>> > of NH >>> > > identity >>> > > > is >>> > > > > > >>>>> just >>> > > > > > >>>>> terrible. Searches for >>> "nhibernate" >>> > "nhibernate >>> > > source" >>> > > > > > >>>>> "nhibernate bug >>> > > > > > >>>>> tracker" "nhibernate docs" >> and >>> > "nhibernate >>> > > binaries" >>> > > > should >>> > > > > > >>>>> all point to a >>> > > > > > >>>>> unified site. >>> > > > > > >>>>> - I don't have anything >> against >>> Jira >>> per >>> > se, >>> > but >>> > > having >>> > > > it >>> > > > > > >>>>> redirect >>> > > > > > >>>>> to an IP is just >> unprofessional >>> > > > > > >>>>> - SourceForge still feels >> like >>> 1999. I >>> > really >>> > > like >>> > > > Google >>> > > > > > >>>>> Code, I >>> > > > > > >>>>> dislike CodePlex, and GitHub >> is >>> meh. >>> But >>> > the >>> > > decision >>> > > > should >>> > > > > > >>>>> be made by >>> > > > > > >>>>> those in charge of >> maintaining >>> it. >>> > > > > > >>> > > > > > >>>>> Diego >>> > > > > > >>> > > > > > >>>>> On Wed, Nov 3, 2010 at 08:03, >>> Ayende >>> Rahien >>> > > > <[email protected]> >>> > > > > wrote: >>> > > > > > >>> > > > > > >>>>>> Frans, >>> > > > > > >>>>>> Git is more popular than hg. >> And >>> we >>> aren't >>> > > considering >>> > > > > > >>>>>> centralized SCM >>> > > > > > >>> > > > > > >>>>>> 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 >>> > > > > > >>>>>> b) it allows you to have your >> own >>> fork >>> and >>> > easily >>> > > merge >>> > > > future >>> > > > > > >>>>>> changes >>> > > > > > >>>>>> c) it means that Joe can pull >> from >>> you, >>> > not just >>> > > from the >>> > > > > > >>>>>> master feed >>> > > > > > >>> > > > > > >>>>>> 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 >>> > > > > > >>> > > > > > >>> -- >>> > > > > > >>> Fabio Maulo >>> > > > > > >>> > > > > > > -- >>> > > > > > > Fabio Maulo >>> > > > > > >>> > > > > > -- >>> > > > > > Fabio Maulo >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> > >>> >>> >>> >>> >> >
