> On Thu, Nov 4, 2010 at 6:24 PM, Frans Bouma <[email protected]> wrote:
> > 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.
>
> *cough* RavenDB has mandatory CLA, it works for us.
I'm happy for you, so with all this major success, why are you still
not moving NH to github?
> Create local copy of trunk, make changes, run tests, create
patch,
> send patch. patch gets applied to trunk, used does update on local
copy
>
> Put a month in the middle, and suddenly this becomes much harder. For
> example, you might need to get approval for submitting your changes.
No, it's the same, as you update your local copy (which is
effectively a branch) with the trunk before creating the patch. If you wait
6 months before sending it, then yes, but that's a problem with whatever
system you use.
> 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.
>
> Or, let us say that you are using the 2.1.x branch, and you patch that, it
> is SO MUCH easier to do cross branch merges in git.
svn merge -r branchrevision:HEAD "svn://repoURL/projectfolder/Trunk"
svn update
svn commit
where branchrevision is the revision when the 3.0 branch was
created. Add to .cmd file and you can repeat it every time. svn 1.5
required.
But Oren, you're so busy defending DVSC which wasn't the point ( I
don't deny it is useful, read!), I mentioned code review problems in a multi
branch merge system.
FB
