@Frans A move to git has been suggested multiple times with a majority being for it.
I am very puzzled how you can be happy with svn. The performance of switching and managing branches/patches is so much quicker and faster. I must be doing something wrong I get tree conflicts all the time when merging / doing svn update after directory renames. If you have a lot of uncommitted changes merged together with svn update conflicts it can be a mess to sort out (some times). I just find gits & mercurials models so much quicker and easier to work with with much fewer conflicts and manual interventions. I know you raised questions regarding mainly code quality process. But at the same time you seemed to imply that svn is fine and git&mercurial does not really bring that much improvement. I am not a comitter, just a couple of patches. /Torkel On 4 Nov, 17:24, "Frans Bouma" <[email protected]> wrote: > > 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. > > there are numerous examples, indeed that's one of them. > > > 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. > > indeed, so if that's the case, then the problem is minor. However I > think being very loose and relaxed about this in the end will lead to less > quality. But perhaps that's me. > > > > > 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. > > Create local copy of trunk, make changes, run tests, create patch, > send patch. patch gets applied to trunk, used does update on local copy, > like everyone else and they all now get the patch. I don't see why history > is a problem for the _trunk_ using people. Sure, if you create branches with > code obtained from others OUTSIDE the trunk, then it's problematic, but NH > is always developed on the trunk, so that's not really a problem IMHO. > > > 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. > > My post wasn't about whether DVCS is capable of doing things :) it > was about who's code reviewing code which is checked in as patches can be > pulled off-trunk more easily than it is done now. It however ended up in a > debate whether dvcs is better or not. Who gives a ****, really. The real > pain is in writing the complex code to fix the harder problems, not whether > some scm is capable of easy merging or creating a patch. If right-clicking > in tortoisesvn -> Create patch is that horrible and time consuming and that > THAT's the reason not more people develop code for NH, then yes, I think > it's wise to move TODAY. But I don't think that's the reason. :) > > > 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. > > as there's apparently only people in favor of DVCS and github and > the rest has 'no clue' then, yes perhaps it is. I still wonder why it hasn't > been moved to github already. I mean, who/what is holding that back? If > everyone is so fond of it, make the decision and move. But it seems svn > isn't that horrible otherwise the move would have already been made (IMHO). > > FB > > > > > > > > > > > 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 > > ... > > läs mer »
