headers
Justin Patrin | 2 May 2008 07:46
Picon

Re: [oe] Reconsidering the work flow and how the SCM system fits in

On Wed, Mar 12, 2008 at 3:21 PM, Paul Sokolovsky <pmiscml <at> gmail.com> wrote:
> Hello,
>
>
>  On Wed, 12 Mar 2008 17:03:13 -0500
>  Mike Westerhof <mwester <at> dls.net> wrote:
>
>  >  On Wed 12/03/08  4:40 PM , Paul Sokolovsky pmiscml <at> gmail.com sent:
>  > ...
>  > > With mtn we seem to have very cheap and robust mirroring and
>  > > high-availability. Well, any DSCM lean on possibility of easy
>  > > mirroring, but Monotone with its super-cool concept of unbelievably
>  > > cheap branches (so-called heads), ...
>  >
>  > Hehe! Yes, and I could describe an automobile spinning out-of-control
>  > on a patch of ice as "unbelievably cheap steering" just as well.
>  > Let's not overlook the fact that the multiple-heads issue with
>  > monotone is very seldom because the person doing it *wished* for that
>  > to happen.
>
>  Vice-versa, as was noted already, we have separate head created
>  almost on each commit (i.e. mtn merge almost always has something to
>  do on each run after commit). So, can one imagine more lightweight
>  branches - they are being created even without any explicit command!
>  Poor git is left far behind with its heavy branch commands! ;-D
>

And just to add insult to injury, this also points out that mtn also
merges very well, with no extra help. The non-content conflicts which
are trotted out again and again are due more to incorrect use of mtn
(Continue reading)

Permalink | Reply |
headers
Mike Westerhof | 12 Mar 2008 23:48
Favicon

Re: [oe] Reconsidering the work flow and how the SCM system fits in

 On Wed 12/03/08  5:32 PM , Paul Sokolovsky pmiscml <at> gmail.com sent:
> Hello,
> 
> On Wed, 12 Mar 2008 23:07:03 +0100
> "Leon Woestenberg" le
> on.woestenberg <at> gmail.com> wrote:
> > Hello Paul,
> > 
> > On Wed, Mar 12, 2008 at 10:40 PM, Paul Sokolovsky pmiscml <at> gma
> il.com>> wrote:
> > >  mirroring, but Monotone with its super-cool concept
> of unbelievably> >  cheap branches (so-called heads), make it just well
> robust - even> > if
> > >
> > Multiple heads and lightweight branches are two
> different things.
> Probably also because of different numbers of hexadecimal digits?
> 
> > 
> > A branch has a name/tag that tells me what is happening
> in that branch> or who is making it happen.
> 
> And heads have head revision and change logs too!
> 
> > 
> > In contrast, multiple heads does not help me in any way
> as a tool for> branching, nor can I easily track someone else's work
> in his "head".
> That's because you've stuck with that old and boring concept of
> "lightweight branches". People who grasped heads novelty enjoy it very
(Continue reading)

Permalink | Reply |
headers
Richard Purdie | 13 Mar 2008 00:18

Re: [oe] Reconsidering the work flow and how the SCM system fits in

On Wed, 2008-03-12 at 17:48 -0500, Mike Westerhof wrote:
> I think this has gotten to the point where the arguments is for the
> sake of arguing, and little else.  I'm surprised that it hasn't been
> mentioned that "hg" has the advantage that its name is only two
> characters, a 33% savings in overhead compared to most other scm tools
> we've discussed.

Agreed, some of the replies are just getting silly now :/.

> So, who makes this decision, and what's the timeframe?

Good question. We have a core team and I guess the first step would be
to put it to a vote there and see where we stand? I'm open to other
ideas and possibly to representations from non core team developers with
a case for a vote too. I would like to get this resolved quickly if we
can though.

Timeframe wise, I liked Holger's end of the month deadline for actually
doing things.

> Oh - btw, lightweight branching implies working, reliable tools to
> identify diffs and merge them, that's the part that really needs to be
> considered rather than how easy it is to just create a branch.

Agreed, although Holger has already compared git's merging capabilities
to monotone...

Cheers,

Richard
(Continue reading)

Permalink | Reply |
headers
Rod Whitby | 13 Mar 2008 01:45
Picon
Gravatar

Re: [oe] Reconsidering the work flow and how the SCM system fits in

Richard Purdie wrote:
> We have a core team and I guess the first step would be
> to put it to a vote there and see where we stand? I'm open to other
> ideas and possibly to representations from non core team developers with
> a case for a vote too.

The nslu2-linux project votes for git, for the following reasons:

1) Most of the nslu2 core team developers are already exposed to git due 
to kernel work.  None of them that I know of are exposed to hg.  Yes, 
that's a selfish position, and yes that means that we're arguing from a 
position of ignorance with respect to hg.

2) None of the nslu2 core team developers have the bandwidth to learn 
yet another SCM, purely for OE.  OE is a means to an end, not an end in 
itself.  Yes, that's a selfish position.

3) Git can support the multiple disconnected-but-syncing servers that 
currently exist in the way that monotone.nslu2-linux.org and 
monotone.openembedded.org work.  We cannot accept a single central 
server model, and I haven't seen anyone state how hg supports the 
multiple equal servers model yet.  But even if hg can support that 
model, we've already dealt with multiple git servers and know how that 
works, so we'd prefer not to need to set up a new system.  Yes, that's a 
selfish position.

4) All arguments against git so far seem to be either "an old version of 
git ate my data" or "git used to be poorly documented".  None of these 
arguments presented seem to be valid going forward in my opinion.
(Continue reading)

Permalink | Reply |
headers
Paul Sokolovsky | 13 Mar 2008 00:10
Picon

Re: [oe] Reconsidering the work flow and how the SCM system fits in

Hello,

On Wed, 12 Mar 2008 17:48:51 -0500
Mike Westerhof <mwester <at> dls.net> wrote:

[]

> I think this has gotten to the point where the arguments is for the
> sake of arguing, and little else.  

Maybe, and on git's side, there's surprisingly little variety of
arguments - 1) "it has lightweight branches" (hg has too, as was pointed
out, but as plugin (which is good) of experimental state (with
obvious entailments)); 2) "I use git, and it works well for me" - it's
hard to respond without calling CVS ghost; 3) "Don't make people learn
more stuff" - and nobody appears to care about people who *don't* know
git - there're still more such potential OE users - is it fair to force
them to learn its quirks, or leave out people who don't want to learn
quirks?

> I'm surprised that it hasn't been
> mentioned that "hg" has the advantage that its name is only two
> characters, a 33% savings in overhead compared to most other scm
> tools we've discussed.

Actually, there's almost noone argues for hg too insistently. Mostly,
there're calls to think better about git.

> So, who makes this decision, and what's the timeframe?
(Continue reading)

Permalink | Reply |

Gmane