Re: Status of blue sky ideas?

Judson Lester wrote:
> Well, that's an incredibly depressing response.  I'm certainly in that 
> group that tends to make tool choices with little concern for "what 
> everyone else is doing."  There are a number of really excellent 
> features of monotone that I'm not aware of anywhere else in VC land. 
>  But there's also a lot of shortcomings that I'd love to see fixed.
I prefer to think of it as the team is resting after the 1.0 release - 
live in hope:-). Thomas was one of  the driving forces behind getting 
1.0 out and he is finding it very difficult to spend the time on 
monotone these days. But certainly start raising tickets and help out. 
Richard Levitte is another key figure.

I have primarily been focused on mtn-browse, a GUI front-end for 
Monotone .But I suspect that if you started a branch and started to work 
on some of these issues you would like to see fixed, raised tickets for 
them etc, then you would hopefully get quite a few people commenting on 
your ideas and reviewing changes.
>
> And certainly, yes, I have to work with git all the time, and I don't 
> like its basic model of revision and commit structure, or its 
> philosophy of rewriting history as a feature.  I am impressed with how 
> it stores history though.
>
> Git also has github going for it, which is pretty huge.  Indefero 
> would be good, but my experience with it so far have been lukewarm.
>
> Anyhow, the story is that Monotone is looking for a new core team?  Is 
> that a correct understanding?
>
> Judson
>
> On Tue, Dec 13, 2011 at 1:25 PM, Bruce Stephens 
> <[email protected] <mailto:[email protected]>> 
> wrote:
>
>     CooSoft Support <[email protected]
>     <mailto:[email protected]>> writes:
>
>     > Bruce Stephens wrote:
>
>     [...]
>
>     > I was thinking about divergences from non-head revisions, in mtn you
>     > just get two heads on the same branch. In git it goes off branch and
>     > the only way you can get back to it is to remember the sha1 hash on
>     > the revision. If it isn't put on a branch then it gets pruned
>     when you
>     > do a git gc.. Other things are also more clunky.
>
>     Technically not true, but I take your point.  It can certainly be
>     non-trivial to find work that you just know you committed.  Not
>     (ordinarily) impractical.  The user manual has a section on it
>     ("Recovering lost changes").
>
>     [...]
>
>     > hehe - a lot of people do not get on with git, goodness knows
>     how many
>     > do.
>
>     Certainly true.  And mercurial seems quite attractive to many: it's
>     similarly fast and space-efficient but with a saner command set.
>
>     > mtn is very good at the day to day stuff, branching merging etc
>     > and the merging on git can make a real mess - I know I have had to
>     > sort  it out (and yes mtn under the same conditions did it
>     perfectly).
>
>     Could be.  I've not noticed any particular problems: for me git's
>     merging has been adequate, really fast, and the rerere support
>     allows it
>     to cope with repeated similar merges (admittedly that seems quite
>     hacky,
>     but it works OK).  Quite possibly I'm just used to the pain.
>
>     What I'm not sure is, given that someone finds the git commands
>     confusing (which isn't difficult to believe) and doesn't like
>     mercurial,
>     how plausible the monotone story is.
>
>     I think I'd look at bazaar and fossil next (not sure in what order).
>     fossil also uses sqlite (is originally written by the author of
>     sqlite)
>     and gives a wiki, bug tracker, web interface as well as a DVCS.
>
>     _______________________________________________
>     Monotone-devel mailing list
>     [email protected] <mailto:[email protected]>
>     https://lists.nongnu.org/mailman/listinfo/monotone-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Monotone-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/monotone-devel
>