[gentoo-dev] Re: Gentoo: State of the Union

[gentoo-dev] Re: Gentoo: State of the Union

[R Hill]

Dan Armak wrote:
> On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote:
>> The commit marked with @ is a special comit called a 'merge'.
>> I hope that clarifies the merge tracking part.
> You just described what merging is. Svn can do that too with svn merge. But, 
> if I merge changesets from branch A to B selectively, skipping some along the 
> way, can I later ask git to:
> 
> - list the changesets remaining in A that I haven't merged to B yet? 
> - list the branches, from a given list, which have/haven't merged a given 
> changeset?
> 
> Those are things svn can't do.
> 
>> However I don't know what do you mean with 'changeset tracking'.
> 
> I didn't mean that 'changeset tracking' is different from 'merge tracking'.

Subversion dev Daniel Berlin was recently hired by Google, and according to his 
blog[i] one of his first duties is to implement merge tracking in svn.

--de.


[i] http://www.dberlin.org/blog/

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo: State of the Union

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Thu, 04 May 2006 11:44:18 +0100
Stuart Herbert <stuart@gentoo.org> wrote:
> However, if you have a separate tree per-arch, that tree can be tested  
> and approved for release as a single unit.

How big would this tree be? Would it be every package? How will this make the arch teams' life easier and/or the users' experience better? I still fail to see how this will work any differently than what we have today. Today we have ~arch, someone tests the package for stability on an arch system, and marks it stable. The tester is effectively integrating the package into a stable system. Maybe you could explain how the procedure might go with branches for getting a package from just put into the tree to ~arch to arch and what happens with version bumps.

~tcort

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-dev] Gentoo: State of the Union

[Molle Bestefich]

> > Having a live tree requires people to be perfect.  People are not
> > perfect and requiring it is ridiculous.  I love having commits in my
> > local tree within the hour, but having a stable and unstable branch
> > makes a lot of sense.
>
> Does it?  How does having a stable and unstable branch differ from
> having stable and unstable keywords?

Agreed.  That doesn't make sense.

Subversion has what is known as pre-commit hooks.
Using those it's very easy to:
 * prevent (most or some) committers from designating ebuilds as stable
 * allow committers to designate ebuilds as stable under a certain path only
 * strictly limit a commiters access to a part of the tree

Slightly harder, but could be done too:
 * deny commits if it breaks ebuild dependencies

If you want central control of what's happening in the repository,
Subversion seems like the way to go.

> SVN requires at least 2x the tree size for storage on the local machine,

This is a feature, not a bug.
It allows you to keep operations local, fx. do a diff without being
online with the repository.

> checkouts take something akin to an order of magnitude longer than CVS.

In the past Subversion performance was sub-par.  I haven't
systematically tested performance, but I would expect it to be much
better now.

Performance is gradually improved, see fx. r18867, r18944 and r19420:
http://svn.collab.net/viewvc/svn?view=rev&revision=18867
http://svn.collab.net/viewvc/svn?view=rev&revision=18944
http://svn.collab.net/viewvc/svn?view=rev&revision=19420

GIT might perform better, since Linus specifically emphasized
non-O(n^2) performance in the design.  But being a decentralized tool,
I'm not sure how well it fits the needs here.

> The former is annoying, but liveable, but
> the latter is a deal-breaker.

I don't think so.  You really rarely do a complete checkout.

> - No changeset/merge tracking

Solutions exist, including svnmerge and svk.
"Official" solution actively worked on at the moment, check out the
svn dev list.

A benefit of Subversion that I personally like is that FSFS
repositories are extremely easy to rsync.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo: State of the Union

[Stuart Herbert]

Quoting Molle Bestefich <molle.bestefich@gmail.com>:

>> Does it?  How does having a stable and unstable branch differ from
>> having stable and unstable keywords?
>
> Agreed.  That doesn't make sense.

It does if you have a separate stable tree per-arch.  With the current  
tree design, it's too easy to break an arch that you've no intention  
of affecting.

However, if you have a separate tree per-arch, that tree can be tested  
and approved for release as a single unit.

 From a SCM point of view, arches are a subset of the full Gentoo  
tree.  They would fit very well into a branching model - and  
Subversion's support for branching would make it a breeze for us to  
support without overloading the arch teams.

> If you want central control of what's happening in the repository,
> Subversion seems like the way to go.

Better to fix the design of the repository, so that it can't be broken  
in the first place, than to try putting band-aids in place to cover  
the gaps.

> I don't think so.  You really rarely do a complete checkout.

I'd be interested to see some stats from our CVS logs to back that up.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                           http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo: State of the Union

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote:
>  From a SCM point of view, arches are a subset of the full Gentoo  
> tree.  They would fit very well into a branching model - and  
> Subversion's support for branching would make it a breeze for us to  
> support without overloading the arch teams.

Are you kidding me?  What about people that commit for multiple arches?
They're now going to have to do the same commit over $x number of trees?
How exactly will that not overload the arch teams?

The more I hear about all of these great features of qall of these
alternative SCM's, the more I think that somebody just has a hard-on for
getting rid of CVS and plans on doing it, no matter the cost to
efficiency and other developers.  No, I'm pointing to anyone in
particular.  It just seems that everyone wants to blame CVS for our
problems, when our problems are almost entirely cultural.

Seriously, if I were forced to commit to multiple trees, or branches, or
whatever, I'd simply leave the project since it would be such an
enormous waste of time.  I'm sure lots of others feel the same.  Our
version control system is supposed to be a tool to help us get our work
done, not a hindrance.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo: State of the Union

[Stuart Herbert]

On 5/4/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote:
> >  From a SCM point of view, arches are a subset of the full Gentoo
> > tree.  They would fit very well into a branching model - and
> > Subversion's support for branching would make it a breeze for us to
> > support without overloading the arch teams.
>
> Are you kidding me?  What about people that commit for multiple arches?
> They're now going to have to do the same commit over $x number of trees?
> How exactly will that not overload the arch teams?

Talking about an SVN perspective ... provided the trees live in a
single repository (which would make a lot of sense), it would be very
straightforward to provide a tool to copy a particular ebuild & its
files from an unstable tree simultaneously to the other trees.  The
difficulties with such a tool would be taking over the right files/
contents (something which is solveable), and what to do about signing
(where a distribtued system like Git probably makes much more sense
anyway).

Given such a tool, you could promote a version of a package to any
number of per-arch trees at the same time.

> The more I hear about all of these great features of qall of these
> alternative SCM's, the more I think that somebody just has a hard-on for
> getting rid of CVS and plans on doing it, no matter the cost to
> efficiency and other developers.

What we're talking about here is a step in the development cycle
commonly called 'integration', where something's taken from the
development bucket, put into the 'release' bucket, and tested to
ensure that it plays nice with everything else already in the
'release' bucket.  It should be listed in RUP, CMM, or whatever
development methodology you use locally in your day job.

Adopting this approach would be far more painful with CVS than with
(say) subversion.  Branch management in subversion is infinitely
easier than with CVS.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo: State of the Union

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thursday 04 May 2006 14:17, Stuart Herbert wrote:
> Talking about an SVN perspective ... provided the trees live in a
> single repository (which would make a lot of sense), it would be very
> straightforward to provide a tool to copy a particular ebuild & its
> files from an unstable tree simultaneously to the other trees.  The
> difficulties with such a tool would be taking over the right files/
> contents (something which is solveable), and what to do about signing
> (where a distribtued system like Git probably makes much more sense
> anyway).

The files content problem should be solved anyway. That way one could even 
make selfcontained ebuild packages including source. A way of 
distributing that would be more appropriate for external ebuilds.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

[gentoo-dev] Re: Gentoo: State of the Union

[Molle Bestefich]

> > If you want central control of what's happening in the repository,
> > Subversion seems like the way to go.
>
> Better to fix the design of the repository, so that it can't be
> broken in the first place, than to try putting band-aids in place
> to cover the gaps.

Wow, way out of scope.
Sure, a Portage that's inherently unbreakable would be nice.
And infinitely more difficult to carry out than what I was proposing.

Also, the two (QA inline in commit process vs. Perfect Portage) does
not preclude each other.  While one may be better long term you
can still do the other to improve quality short term.

(Not that you would need to - if you had a QA step in the commit
 process to make sure that ebuild dependencies were never broken,
 why would you want to create a whole new Portage?

I was trying to say that a QA tool in form of a SVN pre-commit hook
seems like a perfect fit.  The entire infrastructure to run an
external application to check a commit before carrying it out,
approve the commit, send appropriate error messages back to the SCM
client and display them to the user etc. is already in place (and
has been for years) in the Subversion server and any of the client
tools.

The amount of work involved between inventing a couple of rules that
committed ebuilds must obey to actually implementing an enforcement
of said rules is _very_ overcomeable with SVN.

I wasn't even proposing that Gentoo actually needs a QA tool inline
in the process, just saying that it can easily be done [with SVN] :-).


PS. I resent calling it a "band-aid".  It'd be a QA tool built on the
very well-thought-out foundation for quality assurance of commits that
SVN pre-commit hooks happens to be.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Gentoo: State of the Union

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Molle Bestefich wrote:
> I was trying to say that a QA tool in form of a SVN pre-commit hook
> seems like a perfect fit.  The entire infrastructure to run an
> external application to check a commit before carrying it out,
> approve the commit, send appropriate error messages back to the SCM
> client and display them to the user etc. is already in place (and
> has been for years) in the Subversion server and any of the client
> tools.

It's already possible with CVS (unless the gentoo/xml/htdocs/ uses some
uber-tweaked implementation :) ).

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]