> 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.
over a remote line? Sure. Locally, not so sure the difference is
that big.
> 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).
The biggest mistake people make with SVN is that they manage their
repository on disk. Moving a file in a folder on disk and then execute
commit will not move the file in the repository. It will delete the file and
add 'some file with the same name' elsewhere. So do folder management and
file placement in the repository, then do an update. Changing a file simply
requires a commit.
Sourcecontrol is all about scheduling work properly. In a way it's
the same as concurrency control on a database: if you schedule the work
properly, the friction is non-existent. So if you edit the same code in two
repositories, one a branch of the other, and then try to merge changes on
old in new, you'll get merge conflicts. This is logical and also not
avoidable in git. If you have lots of changes in old and new, first commit
new, then merge old.
It still can give headaches sometimes, but with git/hg and other
sourcecontrol systems you also will have problems sometimes, but perhaps in
other areas. SVN is folder oriented, DSCMs like git and hg are repository
oriented. A folder oriented scm is great when you work folder oriented too,
i.e. in svn you can check out a subfolder in a repository somewhere, do some
work and commit the changes to that folder (file changed, added, removed) to
the repository it belongs to. This can offer advantages e.g. when you want
in one project folder a couple of folders being sourcecontrol from a
repository elsewhere.
> 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.
for me it doesn't, but for others it might. I was more debating
pro-svn because of all the fud I read about svn. In the time when many
people were using CVS or VSS, and svn came along, it was heaven. Today, that
same svn is apparently not good for anything, as it seems to fall apart very
quickly. That simply doesn't match the greatness it offered when it became
available, even without merge tracking. It does require knowledge how it
works, otherwise one might run into crap with locked local copies which need
'cleaning' but which aren't cleanable and other mess. Like I said earlier:
they all suck in some case or another and shine in another.
This whole debate really is about central trunk vs. decentralized
trunk, which is as old as stored procs vs. dyn. sql. A good visual overview
of this debate is the video of Linus explaining Git to google's developers
(who use perforce). He had a hard time. The main reason is that if you do
things right with central trunk, there are not that many problems, same is
true with decentralized trunk. If you do things wrong, then yes, it's a land
of pain. But make no mistake, decentralized trunk has drawbacks too, also
areas where you have to do things right to make things work properly. That's
the sadness of this debate: centralized trunk is apparently so utterly
flawed, you'd be stupid to use that.
FB
> 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»
