> Is what you say obtained from experience, either running a project in a
DVCS
> or contributing to one?
running a couple in svn and earlier in CVS (*shiver*). It's also a
matter of how you look at how code emerges towards a release. I'm
supervising that kind of work for over a decade now, getting things done to
a release, version management etc. It's not rocketscience as I said earlier,
but things can get f*cked up if you're not careful, not because of the used
SCM, but because multiple people working on a codebase has the consequence
that if they don't deliver code in the same format, same quality etc.,
someone has to make changes to it. Just because someone on this list had no
trouble with that doesn't mean this isn't a real life problem. But as I
said: it might be the more relaxed standards by others, not sure.
> This discussion reminds me of devs who have only ever used VSS and are
> aghast when they learn that other systems don't lock checked out files.
> "But don't you get conflicts all the time?"
> "No, it rarely happens and is mostly never an issue"
if you think I'm talking about a perspective of a VSS user, you're
mistaken. We use svn for years, with multiple repositories, multiple trunks
(15 or more per version), merging fixes from live branches to new feature
branches every week (if applicable). This used to be problematic as svn
didn't track changes across merges, but since 1.5 it does that and merging
is really simple. The only conflicts we get now are the ones you also get
with git (same lines of code is edited in both branches).
But again, it's about setting a standard, checking if code obeys
that standard and moving on. As there's no standard, everyone can commit
whatever code that works, and I think that also happens (as when it doesn't
fail a test, it must be working correct code). I just wondered, whether this
would become a bigger problem if people start pulling changes from off-main
trunk branches more often than not. I think it will. Others, think it
doesn't. Well, one way to find out, right? :) Sad thing is: if I am right,
it's hard to change it back later.
FB
>
> Richard
>
> On Thu, Nov 4, 2010 at 11:07 AM, Frans Bouma <[email protected]> wrote:
>
>
> > You are confusing theoretical problems with actual problems.
>
>
> I don't think I do.
>
>
> > 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? 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. with patches provided which have to be
> applied to
> the main trunk by a main committer, this is automatic. 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.
>
>
> > 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).
>
> 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
