> 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
