Re: Is monotone dead, or is there a path forward?

[CooSoft Support]

In my experience the merging in mtn presents the developer with far 
fewer conflicts to resolve. Plus you can merge multiple branches in one 
go by `baptising' those dev branches into the target 
developer/integration branch. So it doesn't stand out at first, you just 
notice after a while that you have a lot less work than you'd expect 
with other SCMs.


As for git. Well one of the reasons that mtn is very good at merging, 
apart from any algorithm that is used to do it, is that it relies on the 
fact that you have a complete history and that any branch being merged 
must have branched off at some point from the branch that it is being 
merged back into. Otherwise you have to do a manual merge. Git doesn't 
place that `same origin branch' restriction on you.


Others on this mailing list may have a more in depth answer for you 
though. These are just my observations.

On 06/06/2021 13:49, Hugo Cornelis wrote:


I have used monotone for a few years and was fine with it.

I used to hear a lot and still hear now and then that the approach to 
merging in monotone is / was superior to the approach taken in git.  
It is something I have never understood.  My experience with merges in 
monotone is actually quite limited (compared to experience with merges 
with git).


How do they compare wrt merges?  What is so fundamentally different 
between them?  And why makes this difference such a profound impact to 
the developer experience?


Just wondering.

Would it be possible to integrate monotone-like merges into git?

On Sun, Jun 6, 2021 at 2:32 PM CooSoft Support 
mailto:supp...@coosoft.plus.com>> wrote:


I loved using Monotone and agree that the merging in mtn is far
superior
to the run of the mill merging you get with git (after all it's
site did
refer to it as a stupid/dumb content tracker). In fact mtn's
merging is
the best I've ever used. I liked the fact that changesets were stored
efficiently as compressed deltas in mtn as well. However the world
has
moved on and the projects that I work on have had to switch to git.
Younger developers coming into the organisation know git but have
invariably never heard of mtn. Also git does allow for history
rewriting, which I know is a thorny issue to some, but the reality is

that it is needed and very useful (e.g. someone accidentally
checks in
some creds etc). Whilst you could do this in mtn it was much more


Isn't it just that the term 'history rewriting' was badly chosen?

Something like 'commit refactoring' would have been more appropriate.

Rewriting history sounds as being dishonest.  Commit refactoring 
sounds like moving forward.


Hugo

painful. History is littered with examples of better technology
losing
out over more inferior (remember the video-2000/betamx/vhs debate?).

Moving forward doesn't necessarily mean making progress.
On 06/06/2021 10:00, Michael Raskin wrote:
>> As people noted in last months / years... the worlds OS, apps,
>> developers, and tech oriented operating system / repo / code /
porters
>> eyeballs users and interactors have more or less moved en masse
>> to git, primarily on github, often augmented by running
>> their own git copies in house if they are a large project.
> (for the record, I still run projects where I do not expect too many
> external contributions in Monotone, with a public git repo
explicitly
> marked as «a dump of random snapshots from the real development
> repositories», which makes me kind of interested in having a version
> buildable without using library versions dropped because of open
CVEs)
>
>> It's unlikely under what is now an ecosystem settled
>> into git, that any new talent or otherwise will bother
>> trying to use monotone or any other repo to fetch
>> patch hack commit etc on anyones code, regardless
>> of whether that code is an OS, a repo, or an app.
>> It's the language problem, if you are one speaking Z,
>> in a world where everyone else speaks only A,
>> you will need to adapt to them.
>>
>> If monotone wants to survive in a compileable state
>> across OS, to maintain an example presence that
>> alternative repo embodiments are available that do run
>> and can be studied and tried out, it needs at minimum...
>>
>> a) A tarball release that compiles against the latest
>> versions of all external libraries, and on the latest
>> release of FreeBSD and Linux-Debian.
> Yes, this is clearly a non-negotiable requirement.
>
>> and
>>
>> b) A github repo (and ticket system) that is considered an
>> "upstream" that can be interacted with and that will accept
>>

Re: Is monotone dead, or is there a path forward?

[CooSoft Support]

I loved using Monotone and agree that the merging in mtn is far superior 
to the run of the mill merging you get with git (after all it's site did 
refer to it as a stupid/dumb content tracker). In fact mtn's merging is 
the best I've ever used. I liked the fact that changesets were stored 
efficiently as compressed deltas in mtn as well. However the world has 
moved on and the projects that I work on have had to switch to git. 
Younger developers coming into the organisation know git but have 
invariably never heard of mtn. Also git does allow for history 
rewriting, which I know is a thorny issue to some, but the reality is 
that it is needed and very useful (e.g. someone accidentally checks in 
some creds etc). Whilst you could do this in mtn it was much more 
painful. History is littered with examples of better technology losing 
out over more inferior (remember the video-2000/betamx/vhs debate?).


Moving forward doesn't necessarily mean making progress.
On 06/06/2021 10:00, Michael Raskin wrote:

As people noted in last months / years... the worlds OS, apps,
developers, and tech oriented operating system / repo / code / porters
eyeballs users and interactors have more or less moved en masse
to git, primarily on github, often augmented by running
their own git copies in house if they are a large project.

(for the record, I still run projects where I do not expect too many
external contributions in Monotone, with a public git repo explicitly
marked as «a dump of random snapshots from the real development
repositories», which makes me kind of interested in having a version
buildable without using library versions dropped because of open CVEs)


It's unlikely under what is now an ecosystem settled
into git, that any new talent or otherwise will bother
trying to use monotone or any other repo to fetch
patch hack commit etc on anyones code, regardless
of whether that code is an OS, a repo, or an app.
It's the language problem, if you are one speaking Z,
in a world where everyone else speaks only A,
you will need to adapt to them.

If monotone wants to survive in a compileable state
across OS, to maintain an example presence that
alternative repo embodiments are available that do run
and can be studied and tried out, it needs at minimum...

a) A tarball release that compiles against the latest
versions of all external libraries, and on the latest
release of FreeBSD and Linux-Debian.

Yes, this is clearly a non-negotiable requirement.


and

b) A github repo (and ticket system) that is considered an
"upstream" that can be interacted with and that will accept
maintenance patches from the OS and userspace.

There is a non-trivial chance of success with _just_ a working public
bugtracker and patches mailing list if the development is about API
compatibility fixes.


and

c) Some public FYI blurb advert when doing those interactions,
and in the topline of the toplevel README, that monotone is
accepting new maintenance / dev people. No one lives or
maintains forever, thus wise continually seek new eyballs and
people in wherever the new places are.

Indeed, someone able to make a release whenever APIs need an update is
more important than the quality of such release. (It probably doesn't
have enough changes to break stuff anyway)


Otherwise monotone dies.

If there are compilation and bug patches out there waiting to
be applied, and tarballs with them needing cut, then someone
or some group throwing a monotone continuance project up on
github and working those things there is probably not a bad idea.

Re: [Monotone-devel] interoperating with git

[CooSoft Support]

I can't see why this wouldn't work. Give it a try. The only thing I can 
think of is that Git doesn't track empty directories (I don't know if 
that is an issue for you). One trick is to use a dot file in the empty 
directory - sigh.


When doing this in the past I wanted to preserve all of the history in 
mtn when transferring to git, as sometimes one goes down interesting 
paths that do lead to useful code, just not useful in the current 
context. Something you may want to consider.


Tony.
On 23/10/2018 14:40, Hendrik Boom wrote:

Planning to use monotone together with git.  Monotone for day-to-day
activity, because it's a system I understand and trust.  Git for posting
working versions on github or gitlab or some such.

The obvious way to do this is to have one workspace that is used with
both git and monotone.  git will be tld to ignore _MTN; monotone will be
told to ignore .git .

And. of course, similar treatment with other control files, such as the
one that tells monotone to ignore .git.

Does this seem like a reasonable approach?
Is there something I've overlooked?
Is there a better approach?
Is there some new feature I should be looking at instead?

-- hendrik

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] interoperating with git

[CooSoft Support]

On 23/10/2018 14:40, Hendrik Boom wrote:

Planning to use monotone together with git.  Monotone for day-to-day
activity, because it's a system I understand and trust.  Git for posting
working versions on github or gitlab or some such.

The obvious way to do this is to have one workspace that is used with
both git and monotone.  git will be tld to ignore _MTN; monotone will be
told to ignore .git .

And. of course, similar treatment with other control files, such as the
one that tells monotone to ignore .git.

Does this seem like a reasonable approach?
Is there something I've overlooked?
Is there a better approach?
Is there some new feature I should be looking at instead?

-- hendrik

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone botan-stable AUR

[CooSoft Support]

Oh it's more serious then. For sometime monotone hasn't work with the 
version of Botan that ships with Ubuntu 14.04, I had to regress the 
botan version back to get it to work.


On 28/01/17 13:18, Markus Wanner wrote:

Hi,

I don't really know what's going on in Arch, but...

On 01/16/2017 12:08 AM, Evgeny Pokhilko wrote:

https://aur.archlinux.org/packages/botan-stable/

.. this one works for me.


https://aur.archlinux.org/packages/monotone

This doesn't, but it's not like monotone is anywhere nearly as active as
Botan.

Notably, it won't compile with the newest Botan version.

Kind Regards

Markus Wanner


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone botan-stable AUR

[CooSoft Support]

Oh it's more serious then. For sometime monotone hasn't work with the 
version of Botan that ships with Ubuntu 14.04, I had to regress the 
botan version back to get it to work.


On 28/01/17 13:18, Markus Wanner wrote:

Hi,

I don't really know what's going on in Arch, but...

On 01/16/2017 12:08 AM, Evgeny Pokhilko wrote:

https://aur.archlinux.org/packages/botan-stable/

.. this one works for me.


https://aur.archlinux.org/packages/monotone

This doesn't, but it's not like monotone is anywhere nearly as active as
Botan.

Notably, it won't compile with the newest Botan version.

Kind Regards

Markus Wanner


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone-viz problem

[CooSoft Support]

On 28/06/16 08:43, Markus Wanner wrote:

On 06/26/2016 09:22 PM, Anthony Edward Cooper wrote:

I wrote mtn-browse but haven't got involved in the packaging. There's only so 
much free time... Others have fine excellent work on packaging it for redhat, 
but that doesn't help you.

One can easily install mtn-browse under /opt and the installer will highlight 
missing dependencies.

Mind filing a RFP (request for packaging)?

I already maintain monotone and monotone-viz for Debian.

Regards

Markus Wanner


Many thanks for the offer. I'll file a request this weekend when I'm not 
using a smartphone...


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Mtn-Browse Version 1.20 And AutomateStdio 1.10

[CooSoft Support]

On 09/05/16 05:50, grarpamp wrote:

On 5/8/16, Anthony Edward Cooper  wrote:

Just a quick announcement to say that new versions of mtn-browse and
AutomateStdio have been released. The latter now provides support for
Monotone version 1.10 and the former, in addition, has fixes in it for
running on later Linuxs and KDE 4.x.

You should add news to the website... because it appears dead
and needs an injection.
Sounds like a great idea. I have access to the wiki but I wasn't aware I 
had access to the front page on the main web site. How do you get stuff 
to show up on the RSS feed?

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] improving `mtn status`

[CooSoft Support]

On 12/10/14 15:10, Markus Wanner wrote:

Hi,

it's been a while since the C++11 refactoring, but as promised, here's
some actually useful work: I scratched a couple of itches I had with
recent monotone's status command and started a branch trying to improve
it: net.venge.monotone.revamp-status.

I'm using a mtn from that branch for a while now and am pretty content
with that new status output. Please give it a try as well; I'd
appreciate feedback. In the following, I'm trying to cover the important
changes and the reasoning behind.


The fundamental conceptual mismatch is that the current `mtn status`
basically answers the question: what would happen, if I tried to commit
this, now? Where as I expect it to provide more general information
about the status of my working tree. Oftentimes without any intention of
committing.


The current `mtn status` created a hypothetical revision and prints the
resulting rev id. Often enough, I created copy-pasta from that and was
left wondering why the rev didn't exist. I didn't *ever* need to know
what revid a commit *would* create. Therefore, I consider that
information not just useless, but harmful.


Another message that constantly annoyed me is: THIS REVISION WILL
CREATE DIVERGENCE. Firstly, I perceive it as impolite yelling. And
second, a lot of the time that message is flat out wrong. Some common
scenarios:

  * if you're just inspecting an old revision, it always appears. Even
though you have no intention of ever committing on top of that rev.

  * it even appears if there's no single file changed and it's
impossible to commit such a revision.

  * the message appears in a freshly setup workspace. While technically
correct (there usually are other descendents from the null rev),
it clearly is the users intention to start a new project.

Bottom line: It usually makes me want to yell back: NO! THERE IS NO
SUCH REVISION AND IT WON'T EVER CREATE DIVERGENCE.

However, there's potentially useful information that can be gathered
from that line: It is telling that there is at least one newer revision
and you might want to `mtn up`. The proposed `mtn status` tells you just
that (and even gives a rough estimate on how many revs you can advance).
I consider that more to the point and much less offensive.

Another point: the user might intend to create divergence - no reason
for such a bold warning. That's all fine and monotone is well designed
to deal with divergence.


Some similar points can be made about the message: THIS REVISION WILL
CREATE A NEW BRANCH: There simply is no such revision, yet. (Again, it
might not even be possible to create it.) But it's usually more correct
in that it simply outlines the current user's intention. I personally
still prefer an informative style, rather than having that info yelled
back at me.

Interestingly, it hides the DIVERGENCE message. Granted, given the
user wants to create a new branch, he kind of intends to diverge.
However, the information that the parent revision could be upgraded
(along the old branch) may still be useful. Maybe the users wants to
`mtn up` again, before branching?


So far, `mtn status` only ever listed one branch. However, if the parent
revision is in multiple branches, I consider that useful status
information. Clearly, the current branch - where a commit would go to -
still needs to be shown. The proposed new `mtn status` tries to do that.


Another naughty example - which I consider a bug - is `mtn status` on a
working tree that misses files known to the parent revision (or has
mismatches in type - i.e. file vs directory). For example:


mtn: warning: missing file 'm4/stlporthashmap.m4'
mtn: warning: not a file 'Attic/m4'
mtn: warning: expected file 'Attic/m4', but it is a directory.
mtn: warning: missing file 'm4/tr1unorderedmap.m4'
mtn: misuse: 3 missing items; use 'mtn ls missing' to view.
mtn: misuse: To restore consistency, on each missing item run either
mtn: misuse:  'mtn drop ITEM' to remove it permanently, or
mtn: misuse:  'mtn revert ITEM' to restore it.
mtn: misuse: To handle all at once, simply use
mtn: misuse:  'mtn drop --missing' or
mtn: misuse:  'mtn revert --missing'

Even though some files are missing, mtn should still be able to give me
more elaborate status information - rather than forcing the user to fix
these issues, first.


The nvm.revamp-status branch addresses these issues. It doesn't quite
pass all tests, yet. And there still are minor issues and other UI
issues that I'd like to address, eventually. However, I think it's a
good point in time to ask for feedback, so please have a look and
provide feedback regarding `mtn status`.

Regards

Markus Wanner




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Sounds reasonable to me. I could understand the `would be' revision id 
causing confusion, it never has with me but I can see how it could. As 
for the 

Re: [Monotone-devel] oversized payload

[CooSoft Support]

Hi Hugo,

I don't know the precise answer off the top of my head but I have 
certainly done this with files that are more than 200MiB (getting onto 
300MiB or more). You say it is an archive, is it an archive that can 
sensibly be unpacked and then checked in? Just a thought.


Tony.
On 12/02/14 08:50, Hugo Cornelis wrote:



Hi,


monotone refused to synchronize between a client and server.

On the server side I got the error message

mtn: warning: protocol error while processing peer some ip:50331: 
'oversized payload of '468421054' bytes'


:-)

This happened after adding a large (well, HUGE) file to the 
repository.  I was actually using monotone as a means to distribute an 
archive to several target machines.


To solve the problem, I reverted to a backup repository on the client 
side.


But what is the policy of monotone wrt file size that can be checked 
into a repository?



--
Hugo



--

  Hugo Cornelis Ph.D.

GENESIS-3 -- lead architect
http://www.genesis-sim.org/

Neurospaces Project Architect
http://www.neurospaces.org/


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
   


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone-subversion sync

[CooSoft Support]

I was in exactly the same situation myself. Is it a simple branch to 
branch or trunk to trunk syncing that you are doing?


If so I grabbed a copy of svn_load_dirs that basically implements vendor 
branches in svn (used for going mtn - svn). Going from svn to mtn is 
much easier as mtn can easily do vendor branches.


Someone else on this list may come up with a much better off-the-shelf 
solution though. However in the absence of better ideas I will dig out 
the scripts that I used (all written in Perl and run on Linux) and email 
them to you (I had to modify svn_load_dirs to preserve the history 
comments). Maybe a few days as they were used at work...


Tony.
Jerome Baum wrote:

Hey,

What's the best/recommended option for keeping monotone in sync with a
subversion repository?

I've tried tailor but it barks during the initial svn-mtn transform.
Apart from that I couldn't find much to go by. hg converts from mtn to
hg, and from svn to hg, so maybe combined with tailor that might work --
but I first wanted to ask for input.

Thanks!

Jerome


  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'

[CooSoft Support]

Zack Weinberg wrote:

On 2011-12-31 5:02 PM, Hendrik Boom wrote:

On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote:

I'm not in a position to verify this for myself for another week, but
I have a horrible feeling I know what's wrong:  Monotone defines
several one-character macros for its own use, and L() is one of them.
It looks like Boost is using L() for its own purposes and expecting it
not to be a macro.

...

Or by changing the name of L.


L and several other one- or two-character macros (from memory: F, FL, 
I, M, MM; there are probably at least two more) are used dozens of 
times in every file -- and more important still, the coding style 
assumes they are short-yet-mnemonic.  I cannot support changing them.
With such short names they are bound to clash at some point with some 
3rd party software. You could prefix them with a namespace, say MTN_... 
so have MTN_L() etc.


zw

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Status of blue sky ideas?

[CooSoft Support]

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 
monot...@cenderis.demon.co.uk mailto:monot...@cenderis.demon.co.uk 
wrote:


CooSoft Support supp...@coosoft.plus.com
mailto:supp...@coosoft.plus.com 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
Monotone-devel@nongnu.org mailto:Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Status of blue sky ideas?

[CooSoft Support]

Thomas Keller wrote:

Am 13.12.11 00:33, schrieb Judson Lester:
  

[...] So, seeing an email from a few months back that seemed to suggest that
monotone is kind of done - no one seems to be keen to continue
development, and everyone seems satisfied - was a little disheartening.

What is the status of monotone as a project?



Software - and especially Open Source software - is only insofar
complete as long as no one complains about something and eventually
hacks on it.

The thing with monotone now is probably that there are just too few
people using and therefor possibly complaining (enough) about stuff. And
even if they'd complain, the alternatives seem - most of the time - much
more attractive.
  
I used git recently, and quite frankly give me monotone any time. Git is 
far too complex in certain areas and it's easy to loose stuff. Very fast 
though. We use Perforce at work, quite good really. But again with great 
power comes great complexity. Monotone does 98% of what most people want 
out of an SCM system but it is very simple to do the important things 
(not so with Perforce). The die-die-die merge could be a lot better, git 
has a nice way of doing it (but then it needs to be good as it seems 
rubbish at the actual auto-merging itself). Hopefully more people are 
using it than we think and are just happy with it - I know dream on...


Perhaps more plugging of mtn on the internet? To get the git rejects?

Also a lot of people put a lot of effort into getting 1.0 out the door. 
I'm nearly there with mtn-browse. And it's only natural that people take 
a breather afterwards... I will.

monotone's code base ages in the meantime, and while it is still very,
very sophisticated in many areas, it might just scare away younger devs
because its C++, and not Ruby, or Python, or Java.

So yes, development kind of ceased, and I'm not happy on that fact
either, but its actually all about participation. It brings us nothing
to whine about the fact that nobody hacks on it; if you, or me or
anybody else _cares_ about monotone and starts hacking on it again, than
it will live further, if not, it will die. Its as simple as that.

Unfortunately my personal time for open source projects is very, very
limited these days, so I cannot bring much into this anymore. We really
need fresh blood...

Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Status of blue sky ideas?

[CooSoft Support]

Bruce Stephens wrote:

CooSoft Support supp...@coosoft.plus.com writes:

[...]

  

Git is far too complex in certain areas and it's easy to loose
stuff.



Too complex?  In some sense, yes.  The set of commands is rather random,
not consistent (it's obvious that much of it grew rather than being
designed).  I disagree that it's easy to lose things: it's easy to throw
things away, but once you've committed something it's difficult to lose
it (unless you remove .git, which I guess isn't impossible coming from
monotone where the database is outside your checkout).
  
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.

[...]

  

Perhaps more plugging of mtn on the internet? To get the git
rejects?



Make sure you've got something to offer.  Back in the day there weren't
many practical DVCSs, but nowadays I'd guess that fossil would be a more
likely refuge for people who don't like git or mercurial.  (Not sure who
bazaar attracts; I find it peculiarly opaque.)

  
hehe - a lot of people do not get on with git, goodness knows how many 
do. 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).


The only reason I don't recommend mtn in all situations is for 
MS-Windows users that are used to desktop integration. Perhaps that is 
an area to concentrate on,

[...]


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone suppresses .svn directories.

[CooSoft Support]

Evil make system relying on the .svn dir.

Or you an do something like:

mtn add --no-respect-ignore --recursive

if you just want to add all files in a one off operation, your mtn 
config is not changed (normally you would want to ignore the .svn dirs).


mtn is really good at simply dealing with vendor branches, used this 
technique to do a CVS to mtn import.


Tony.

Stephen Leake wrote:

Hendrik Boom hend...@topoi.pooq.com writes:

  

How can I do the recursive mtn add and suppress the .svn suppression?



.svn is in the standard Lua function 'ignore_file'; you can override
that function definition in your ~/.monotone/monotonerc

Or you can add the .svn directly; then it will no longer be ignored.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone suppresses .svn directories.

[CooSoft Support]

Hendrik Boom wrote:

On Tue, Nov 29, 2011 at 09:58:12AM +, CooSoft Support wrote:
  

Evil make system relying on the .svn dir.



Yeah.  I thought so too.  I gather that, if the .svn is present, is 
assumes you're building from scn, but otherwaise, you're building from a 
source tarball, which isn't quite just source;  it contains some 
files that are build using obsure, hard-to-get tools.  At least, they 
think they're not likely to be in everyone's repertoire, perhaps from 
platform limitations.


-- hendrik

  

Or you can do something like:

mtn add --no-respect-ignore --recursive

if you just want to add all files in a one off operation, your mtn
config is not changed (normally you would want to ignore the .svn
dirs).



I hope it still ignores the _MTN diractory!
  

lol - yes it does :-)
  

mtn is really good at simply dealing with vendor branches, used this
technique to do a CVS to mtn import.



Exactly.  That's why I want to use monotone for this.  Thanks.

- hendrik

  

Tony.

Stephen Leake wrote:


Hendrik Boom hend...@topoi.pooq.com writes:

  

How can I do the recursive mtn add and suppress the .svn suppression?


.svn is in the standard Lua function 'ignore_file'; you can override
that function definition in your ~/.monotone/monotonerc

Or you can add the .svn directly; then it will no longer be ignored.

  

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] New BETA RC 1 Version Of Mtn-Browse

[CooSoft Support]

   Richard,

  Many thanks for the patch :-).

   Why no mtn-browse-sv2 in mtn?

   Well I am currently having to maintain two versions of files for 
mtn-browse and HistoryGraph.pm (Gtk2-SourceView1 vs 2, and Canvas text 
items vs labels respectively).  Rather than have these simply checked in 
and have to replicate changes made to one also to the other, I have 
checked in patch files that I use to to generate one file from the 
other. That way I only have one set of files to maintain. Luckily both 
variants in both files are relatively self contained and are in code 
that is unlikely to change.


   I generate these files when packaging.

   Cheers,

   Tony.
Richard Levitte wrote:

There's an error in Makefile.PL that gets make, patch (based on the
current head) attached.

Also, is there a reason mtn-browse-sv2 isn't added in
net.venge.monotone.contrib.mtn-browse?

Cheers,
Richard

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone-viz colours

[CooSoft Support]

   Are ok many thanks for that...:-)

Richard Levitte wrote:

In message 4e02f059.9090...@coosoft.plus.com on Thu, 23 Jun 2011 08:50:49 +0100, 
CooSoft Support supp...@coosoft.plus.com said:

support Yup its a try it an see I'm afraid. There is also a right click menu
support that is very useful if you haven't discovered that yet. The only thing
support I haven't quite figured out yet is what the orange arrows signify.

It means that the second revision is in a different branch than the
first one.  For example, a propagate looks like that.

There was an error in the description of dotted line boxes earlier, by
the way.  The dotted line box signifies that it's extra information,
for example the end revision of a orange arrow that would normally not
be shown because it's not one of the branches asked for, but still is
at the end of said arrow.

Cheers,
Richard

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone-viz colours

[CooSoft Support]

Yup its a try it an see I'm afraid. There is also a right click menu 
that is very useful if you haven't discovered that yet. The only thing I 
haven't quite figured out yet is what the orange arrows signify.


Tony.

Richard Levitte wrote:

In message 20110620160045.ga19...@topoi.pooq.com on Mon, 20 Jun 2011 12:00:45 
-0400, Hendrik Boom hend...@topoi.pooq.com said:

hendrik On Mon, Jun 20, 2011 at 09:33:07AM +0200, Thomas Moschny wrote:
hendrik  Hendrik Boom hend...@topoi.pooq.com:
hendrik  
hendrik   monotone-viz is giving me a nice display.  But is it documented 
hendrik   somewhere what the pretty colours mean?  And whether boxes are

hendrik   outlined with solid or dotted lines?
hendrik  
hendrik  Same color means same comitter (or author, not sure).
hendrik  
hendrik  Boxes with dotted lines are from different branches and a double click

hendrik  on such a block switches to a view of that branch.
hendrik  
hendrik  - Thomas
hendrik 
hendrik And the circle?  Is that the current workspace, which is not 
hendrik yet checked in?  Or is it a way to mark the head(s)?


The circle is a merge.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] New branch name with no other changes

[CooSoft Support]

Nuno Lucas wrote:

Hello,

On Mon, Jun 13, 2011 at 00:14, Stephen Leake
stephen_le...@stephe-leake.org wrote:
  

Hendrik Boom hend...@topoi.pooq.com writes:


So my real problem was not knowing about the approve command.  I may
have heard about it before, but if I did assumed it was for reporting on
the success of testing, rather than providing a branch name.
  

Hmm. I would have thought so, too. But that's not what the manual says
(http://www.monotone.ca/docs/Review.html#Review); it seems 'approve' is
a synonym for the 'cert' command I use for creating a new branch.

I guess it makes sense when compared to 'disapprove', but it sounds odd
in my (our) work flow.

'testresult' is for recording the results of testing.



In my view, any of those commands do what one wants when creating a
fork, but none is clear on what it does.

I would vote for a mtn fork new_branch_name command. If no options
given would create a new branch on the current workspace revision.
No workspace update would be done by default, but could be done by
adding --update (or -u).
Other option would be -r revision, so one could fork from a
specific revision independently of the current workspace.
A third, arguable, option could be if the commit is real (cert) or
virtual (just changes the _MTN/options file). It could be a
--delayed or --local option. But I don't have strong feelings
about this one.

I don't have a very strong reason to add this command. But I find that
I create a new branch rarely enough that I always have to go see the
manual on how to do it. And doing it at commit time is too late in the
game -- most of the time I have to undo that commit because I forgot
to branch.

The decision to branch is done mostly a long time before the real
commit, so there is a good chance to forget about it at commit time.
Doing dummy commits or manually editing the _MTN/options file feels dirty.

Well, this is just to give an user opinion (using monotone since 0.20
something). Feel free to disregard.
  
This is exactly why we adopted  the mtn cert ; mtn update approach to 
creating branches, because one forgets at check in. :-)


I guess one could use lua to add your proposed fork command, but 
wouldn't branch perhaps a better name as in mtn branch... or would that 
be too confusing?


My _slight_ concern is that mtn provides an easy enough way to do this 
at the moment using two simple commands and we might start down the road 
of interface clutter as one can see with such tools as git.


1) Yes the documentation, which I think is very good btw, needs to make 
the alternate `mtn cert... mtn update' approach to branching much more 
obvious than it is now and why you might want to do it that way as 
against the mtn ci -b way.


2) Implement a global rc file mechanism, I read the comment about 
wrapping it in a script, yup that is a possibility (certainly for now). 
but most tools have the concept of global and user rc files. If this was 
done then interface extensions could more easily/practically be rolled 
out via the extras package.


Maybe the documentation needs a FAQ section?

Either way these are just passing idle thoughts and ideas. As Nuno said, 
feel free to disregard. :-)


Tony.



Best Regards,
~Nuno Lucas

  

--
-- Stephe



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] New branch name with no other changes

[CooSoft Support]

   I quite agree with the `support the workflow via lua' approach 
below. Mtn provides what you need and the interface is currently clean 
and simple.


   One thought I had is that it would be nice to have the ability to 
specify a site wide/system wide LUA file so that you could set it up in 
one place and all users would by default pick it up. Rather like Emacs's 
site.el file. Or can one do that now anyway?


   I have had the misfortune to use Git, it has a overly cluttered and 
some would say confusing interface. BTW you create a branch in git on 
check in, a bit like mtn ci -b... I don't think it offers the mtn cert 
pre checkin approach, well not that I could see.


   Tony.

Stephen Leake wrote:

Richard Levitte rich...@levitte.org writes:

  

However, as far as I understand, Hendrik really just wants the next
commit to end up in the new branch.  The simplest way to do that is to
edit the branch setting in _MTN/options...  I really think we should
have a 'mtn branch' that does exactly that.  Last time I suggested
that, there were a number of comments arguing the idea on grounds I'm
not sure I've understood...



One objection would be from me; I want a variant of the command that
just adds a branch cert to the current revision, without changing the
workspace, because that's what my workflow requires. 


It could be difficult/confusing to have one command that does either of
those things.

Something like 'mtn edit-options branch newbranch' would be good; it
could also edit other fields in _MTN/options.

Then people would complain why do I have to use this weird
'edit-options' thing just to add a new branch, just like now we
complain about using 'cert' just to add a new branch :).

mtn provides the core facilities; users get to implement many different
workflows.

Which is why I wrote a set of user commands to enforce/support my
workflow, rather than pushing for 'mtn branch' that does what I want.

Perhaps it would be useful to put my set of commands in mtn/examples.

How do other DVCs handle this? git, mercury?

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] New branch name with no other changes

[CooSoft Support]

We use the `mtn cert branch... mtn update to new branch' approach on our 
project at work. All changes are done on their own branch and we felt 
that setting up the new branch beforehand would be far less likely to 
cause problems (only approved work would be started). We felt that 
hoping a dev would remember to use the -b switch on their first mtn ci 
was more error prone (especially when they weren't used to the tool at 
that point).


With mtn you get to choose :-)

And yes you get the revision where the fork took place being on two 
branches, but as you would expect, this caused no issues.


Tony.
Richard Levitte wrote:

In message 4df22cfb.60...@thomaskeller.biz on Fri, 10 Jun 2011 16:40:59 +0200, 
Thomas Keller m...@thomaskeller.biz said:

me Am 10.06.2011 16:26, schrieb Hendrik Boom:
me  Actually, the approve command worked fine, though it took a few moments 
me  to determine the right revision ID.  Maybe approving the revision in the 
me  current workspace should be an option on that command?  I wouldn't want 
me  it to be the default: too easy to approve the wrong thing by accident.
me 
me You could use
me 
me 	mtn approve -b new.branch w:
me 
me for the very same purpose and don't have to figure out the current rev

me id at all.

But that places the current revision in the new branch as well.  Was
that Hendrik's intention, or was the intention that the next revision
should end up in the new branch?

What you'r forgetting, by the way, is that approve will not place the
workspace in the new branch, so the next commit after that will end up
in the original branch.  I don't think that was Hendrik's intention.
So for completeness, you really need the following:

mtn approve -b new.branch w:
mtn update -r h:new.branch

However, as far as I understand, Hendrik really just wants the next
commit to end up in the new branch.  The simplest way to do that is to
edit the branch setting in _MTN/options...  I really think we should
have a 'mtn branch' that does exactly that.  Last time I suggested
that, there were a number of comments arguing the idea on grounds I'm
not sure I've understood...

Cheers,
Richard

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Updated Issue 156 - mtn 1.0 (and some others have build/run failures) (monotone)

[CooSoft Support]

Blast - didn't notice the PCRE discrepancy...

Basically all packages that I built just used the standard options on 
configure apart from installation location (my intention is to build a 
stand alone binary with most dependencies statically built in like the 
main official binaries produced by the Monotone project).


Interesting about the Botan point. I'll have a fiddle around with it 
this weekend and see if either of those make a difference (the PCRE 
linkage needs to be fixed anyway). This might explain why once I had a 
binary that worked on Intel and not on AMD...


Many thanks Stephen - I'll get back to you and/or update the ticket.

Cheers,

Tony.
c...@monotone.ca wrote:

Hello,

The following issue has been updated:

156 - mtn 1.0 (and some others have build/run failures)
Project: monotone
Status: New
Reported by: Tony Cooper
URL: https://code.monotone.ca/p/monotone/issues/156/
Labels:
 Type:Crash
 Priority:Medium

Comments (last first):

# By Stephen Leake, Mar 29, 2011:

The stack trace indicates that Botan is trying to use SSE2 instructions; does 
your CPU actually have those?

Did you compile Botan from source? If not, try that, and try explicitly 
disabling SSE2.

Also, the PCRE versions don't match; it says you compiled with version 7.9, but 
are using 4.5 runtime library.

# By Tony Cooper, Mar 27, 2011:

I have experienced two problems when building and running mtn on WhiteBox Linux 
4 respin 2 (pretty much equivalent to RHAS 4.2/4.3 Intel 32 bit).

1) The link command for mtn is missing -ldl and -lrt. Adding these makes it 
link ok. (-lrt needed for clock_gettime() and -ldl for a number of the dl 
library routines).

2) When run for most things it errors with an illegal instruction message:

-
$ mtn --db=test-1_00.mtn db init
mtn: fatal signal: Illegal instruction
this is almost certainly a bug in monotone.
please send this error message, the output of 'mtn version --full',
and a description of what you were doing to 
https://code.monotone.ca/p/monotone/issues/
do not send a core dump, but if you have one, 
please preserve it in case we ask you for information from it.

Illegal instruction
-

mtn version --full gives:

-
monotone 1.0 (base revision:
3405a2457cf8869f247a293d30cfe3a41b5eb5a2)
Running on  : Linux 2.6.9-34.EL #1 Sun Mar 19 13:34:16 CST 2006 i686
C++ compiler: GNU C++ version 3.4.5 20051201 (Red Hat 3.4.5-2)
C++ standard library: GNU libstdc++ version 20051201
Boost version   : 1_33_1
SQLite version  : 3.4.2 (compiled against 3.4.2)
Lua version : Lua 5.1
PCRE version: 4.5 01-December-2003 (compiled against 7.9)
Botan version   : 1.8.2 (compiled against 1.8.2)
Changes since base revision:
format_version 1

new_manifest [b252820fde344fd3f5d023fd91de86522baa671d]

old_revision [3405a2457cf8869f247a293d30cfe3a41b5eb5a2]

patch NEWS
 from [c636641e064654102ff4c37362c07cad9726c7a2]
   to [282addc1d59cc722b9e713aa5e04605e9bd2289d]

  Generated from data cached in the distribution;
  further changes may have been made.
-

I should also say that I have never had issues with the pre-built binaries.

I can provide an strace should that be useful.

Running in a debugger I get the following stack trace at the time the signal is 
caught:
#0  0x08515843 in botan_sha1_sse2_compress ()
#1  0x in ?? ()

Cheers,

Tony.



--
Issue: https://code.monotone.ca/p/monotone/issues/156/

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] [ANNOUNCE] monotone 1.0 released

[CooSoft Support]

   This is excellent news - A VERY big thank you to all those that have 
helped make this happen :-)


Richard Levitte wrote:

Monotone 1.0 is out!

We, the monotone developers, are very proud to release version 1.0 of
our distributed version control system.

This is a major milestone, and a lot of effort has been made to make
this release a reality.  It contains quite a number of bug fixes,
changes and new features.  The tarball can be downloaded here [0],
binaries are posted on the same page as they come in.

Following is the relevant part of the NEWS [1] file:

Sat Mar 26 10:53:47 UTC 2011

1.0 release.

Changes

- The database scheme was changed; please execute 'mtn db migrate'
  on all your local and remote databases.

- In 'mtn conflicts resolve_first interactive', the result
  file name now defaults to _MTN/resolutions/left_path.
  (fixes monotone issue 103)

- The French monotone translation has been updated and is
  now part of the main distribution again. Many thanks to
  Steve Petruzzello dl...@bluewin.ch for the outstanding
  work!

- get_netsync_(read|write)_permitted have been extended to not
  only read the files read-permissions and write-permissions,
  but also the files in the subdirectories read-permissions.d
  and write-permissions.d.

- monotone now also tracks the workspaces of databases which
  do not reside in a managed location.

- automate now resets the locale to POSIX internally.  This
  means that all scripts can expect the same untranslated
  messages from mtn automate, regardless of the locale of the
  calling process.

- The hook 'get_netsync_key' has been split up into two separate
  hooks, one for client usage ('get_netsync_client_key', with
  the same arguments as the original 'get_netsync_key') and one
  for server usage ('get_netsync_server_key', with a single table
  argument containing all the given '--bind' options).  Please
  review your custom hooks accordingly.

- Short options ('-b', '-d', ...) are no longer completed.  This
  fixes an invariant failure originating from wrong option usage.
  (closes monotone issue 141)

New Features

- 'mtn conflicts store' now outputs a count of the conflicts,
  and the name of the conflicts file.
  (fixes monotone issue 108)

- New 'mtn list workspaces' command which outputs all the
  known workspaces for a specific database.
  (closes monotone issue 129)

Bugs fixed

- The internal line merger will actually preserve your line
  endings now, instead of changing everything to \n.

- Improved the help and fixed the argument indexing in
  'conflicts resolve_first' (fixes monotone issue 101)

- A regression from 0.48 prevented monotone from ordering the
  diff output of individual files alphabetically.
  (fixes monotone issue 102)

- 'mtn privkey' did not recognize private keys solely available
  in the key store. This has been fixed.

- Added compatibility with Botan 1.9.9 and newer.
  (fixes monotone issue 104)

- 'mtn pull' and 'mtn sync' would always say that your workspace
  has not been updated.  Now, it only does that when you used
  the '--update' option and there were no updates.
  (fixes monotone issue 106)

- 'mtn automate remote' and 'mtn automate remote_stdio' now use
  a given database given by an alias to read, store and validate
  a remote server's key fingerprint (fixes monotone issue 95)

- monotone gives a proper error message now if a netsync URI
  with the 'mtn' scheme misses the required host part
  (fixes monotone issue 110)

- Whenever a binary file was removed and one would try to get
  a diff using mtn diff, it would report that /dev/null is
  binary.  This has been changed to it reports the actual
  name of the removed file instead.
  (fixes monotone issue 111)

- monotone no longer wrongly falls back on a :memory: database
  when no database option is given. It also prints out an
  informational message for commands like 'setup' and 'clone'
  that fall back on the configured default database, again,
  if no database is specified for these commands.
  (fixes monotone issue 113)

- If 'mtn serve' is called with one or more '--bind' options,
  then the arguments to these options can now be specified
  again as follows:

'ip-or-host'
to listen to IP or host on the default port
'ip-or-host:port'
to listen to IP or host on the specified port  - or
':port'
   

Re: [Monotone-devel] [ANNOUNCE] monotone 1.0 released

[CooSoft Support]

   I tried building from source and my binary went bang (illegal 
instruction). This is what has happened since about 0.48, I'm sure I'm 
doing something wrong but it's not obvious (dependencies are met or so 
it seems). I normally download the binary from the site now. Any idea 
when the mtn-1.00-linux-x86.bz2 file will be ready for downloading?


   Cheers,

   Tony.
Richard Levitte wrote:

Monotone 1.0 is out!

We, the monotone developers, are very proud to release version 1.0 of
our distributed version control system.

This is a major milestone, and a lot of effort has been made to make
this release a reality.  It contains quite a number of bug fixes,
changes and new features.  The tarball can be downloaded here [0],
binaries are posted on the same page as they come in.

Following is the relevant part of the NEWS [1] file:

Sat Mar 26 10:53:47 UTC 2011

1.0 release.

Changes

- The database scheme was changed; please execute 'mtn db migrate'
  on all your local and remote databases.

- In 'mtn conflicts resolve_first interactive', the result
  file name now defaults to _MTN/resolutions/left_path.
  (fixes monotone issue 103)

- The French monotone translation has been updated and is
  now part of the main distribution again. Many thanks to
  Steve Petruzzello dl...@bluewin.ch for the outstanding
  work!

- get_netsync_(read|write)_permitted have been extended to not
  only read the files read-permissions and write-permissions,
  but also the files in the subdirectories read-permissions.d
  and write-permissions.d.

- monotone now also tracks the workspaces of databases which
  do not reside in a managed location.

- automate now resets the locale to POSIX internally.  This
  means that all scripts can expect the same untranslated
  messages from mtn automate, regardless of the locale of the
  calling process.

- The hook 'get_netsync_key' has been split up into two separate
  hooks, one for client usage ('get_netsync_client_key', with
  the same arguments as the original 'get_netsync_key') and one
  for server usage ('get_netsync_server_key', with a single table
  argument containing all the given '--bind' options).  Please
  review your custom hooks accordingly.

- Short options ('-b', '-d', ...) are no longer completed.  This
  fixes an invariant failure originating from wrong option usage.
  (closes monotone issue 141)

New Features

- 'mtn conflicts store' now outputs a count of the conflicts,
  and the name of the conflicts file.
  (fixes monotone issue 108)

- New 'mtn list workspaces' command which outputs all the
  known workspaces for a specific database.
  (closes monotone issue 129)

Bugs fixed

- The internal line merger will actually preserve your line
  endings now, instead of changing everything to \n.

- Improved the help and fixed the argument indexing in
  'conflicts resolve_first' (fixes monotone issue 101)

- A regression from 0.48 prevented monotone from ordering the
  diff output of individual files alphabetically.
  (fixes monotone issue 102)

- 'mtn privkey' did not recognize private keys solely available
  in the key store. This has been fixed.

- Added compatibility with Botan 1.9.9 and newer.
  (fixes monotone issue 104)

- 'mtn pull' and 'mtn sync' would always say that your workspace
  has not been updated.  Now, it only does that when you used
  the '--update' option and there were no updates.
  (fixes monotone issue 106)

- 'mtn automate remote' and 'mtn automate remote_stdio' now use
  a given database given by an alias to read, store and validate
  a remote server's key fingerprint (fixes monotone issue 95)

- monotone gives a proper error message now if a netsync URI
  with the 'mtn' scheme misses the required host part
  (fixes monotone issue 110)

- Whenever a binary file was removed and one would try to get
  a diff using mtn diff, it would report that /dev/null is
  binary.  This has been changed to it reports the actual
  name of the removed file instead.
  (fixes monotone issue 111)

- monotone no longer wrongly falls back on a :memory: database
  when no database option is given. It also prints out an
  informational message for commands like 'setup' and 'clone'
  that fall back on the configured default database, again,
  if no database is specified for these commands.
  (fixes monotone issue 113)

- If 'mtn serve' is called with one or more '--bind' options,
  then the arguments to these 

Re: [Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12

[CooSoft Support]

   Excellent - Many thanks for that Thomas :-)

   I was thinking of switching the external comparison tool over to 
kdiff3 to match with the recommended merge tool for monotone but 
unfortunately that also suffers from the KDE dependency thing (as you 
would expect).


   Good point. It does seem a little bit 'odd' that a Gtk tool has a 
dependency on KDE. So unless anyone has any objections, I'll switch to 
meld. Remember that this setting just specifies the default application 
to use, the user is free to change it under their own preferences to 
what ever they want. So I think this is more an issue for packagers... 
Please let me know if you don't like this decision.


   I'm also in the process of setting up a Debian 6 vm to look into 
switching over to Gtk2::SourceView2 (as highlighted by Richard). 
Hopefully this will be a simple name change in the code and so I may be 
able to get the installer to select the right package depending upon 
what it finds on the target distro.


   Many thanks,

   Tony.

Thomas Moschny wrote:

Am Sat, 05 Mar 2011 15:05:01 +
schrieb CooSoft Support supp...@coosoft.plus.com:

  

Just a quick email to announce the release of the above software
on source forge and CPAN respectively.

Basically the main work was to get these packages working with 
version 0.99.1 of Monotone.


Monotone Browser, not only having the new selectors introduced in 
0.99.1, also now has the ability to restrict revision and file

histories to specific branches.



Just fyi, Fedora packages have been put up for review:

 https://bugzilla.redhat.com/show_bug.cgi?id=684407
 https://bugzilla.redhat.com/show_bug.cgi?id=684433

Btw, I changed the default FILE_COMPARISON tool from kompare to
meld, to not drag in too many KDE packages for Gnome user.

Regards,
Thomas

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Soon time for a release

[CooSoft Support]

   Cool :-)
Richard Levitte wrote:

In message 82r5ax6ey4@stephe-leake.org on Thu, 24 Feb 2011 02:59:15 -0500, 
Stephen Leake stephen_le...@stephe-leake.org said:

stephen_leake Richard writes:
stephen_leake 
stephen_leake  In message 82y657td7g@stephe-leake.org on Wed, 23 Feb 2011 02:36:03 -0500, Stephen Leake stephen_le...@stephe-leake.org said:
stephen_leake 
stephen_leake stephen_leake Richard Levitte rich...@levitte.org writes:
stephen_leake stephen_leake 
stephen_leake stephen_leake  2. go through the contrib/ directory and see what can and should be

stephen_leake stephen_leake moved to somewhere in extra/, be moved 
somewhere else (the wiki
stephen_leake stephen_leake on a 'tricks and tips' or 'contributed 
stuff'?), or tossed.
stephen_leake stephen_leake If you want to toss something, please talk 
with the original author
stephen_leake stephen_leake first.
stephen_leake stephen_leake 
stephen_leake stephen_leake Is the goal to completely eliminate the contrib

stephen_leake stephen_leake directory, or can there be some stuff left in it?
stephen_leake 
stephen_leake  The longer term goal is that contributed stuff get moved somewhere

stephen_leake  else, see my post from Feb 4:
stephen_leake  
http://article.gmane.org/gmane.comp.version-control.monotone.devel/18838
stephen_leake 
stephen_leake Ok, that makes sense. But let's focus on 1.0; what is the release

stephen_leake criteria? Does contrib have to be empty?

That is the wish, yes.  However, I wouldn't make that the highest
priority, unless someone (you?) is very determined.

I've made a start, have a look at http://wiki.monotone.ca/extra, where
I've added a few pages already.  Some of them describe things that we
have already moved to extra/, and then, there are the contributed
ones, which would basically be those taken from contrib/, or anything
else we'd like to present (I added Monotone::AutomateStdio, as an
example), in http://wiki.monotone.ca/extra/contrib/.

I've added a couple of templates to help make sure we have a few
things in one or two infoboxes.  They are (description URL in parens):

 - extra (http://wiki.monotone.ca/templates/extra/)
   This is mandatory.
 - repository (http://wiki.monotone.ca/templates/repository/)
   This is optional for source that isn't directly in the wiki or in
   the monotone source.

Those templates are to be used with the ikiwiki template directive
(see http://ikiwiki.info/ikiwiki/directive/template/)

Cheers,
Richard

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Release Of Monotone Browser 0.72 And Monotone::AutomateStdio 0.12

[CooSoft Support]

   Just a quick email to announce the release of the above software on 
source forge and CPAN respectively.


   Basically the main work was to get these packages working with 
version 0.99.1 of Monotone.


   Monotone Browser, not only having the new selectors introduced in 
0.99.1, also now has the ability to restrict revision and file histories 
to specific branches.


   Regards,

   Tony Cooper.

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Soon time for a release

[CooSoft Support]

   One thing, mainly for my stuff, is has there been any automate stdio 
changes made since 0.99.1? I had a quick look at the nightly doc stuff 
and couldn't see anything obvious. I aim to release the MAS library and 
mtn-browse at 1.0 roughly at the same time.


   My revision graphing module will have to wait until 1.1 of 
mtn-browse :-(.


   April the 1st - that would be a classic!... But yes perhaps the 2nd 
would be better


   Tony.
Richard Levitte wrote:

Hey there,

Some time furign the winter (when we realised a Christmas release
would be impossible), we said that we would release monotone v1.0
withing Q1 2011.  Q1 ends in a little more than a month (*), so it
might be time to wrap it up a bit.

The things I see left to do is this:

1. have a look at the open issues, try to classify the issues in
   milestones they should go into or simply fix them if it seems
   appropriate.
2. go through the contrib/ directory and see what can and should be
   moved to somewhere in extra/, be moved somewhere else (the wiki
   on a 'tricks and tips' or 'contributed stuff'?), or tossed.
   If you want to toss something, please talk with the original author
   first.
3. at some point, we will create a separate branch for v1.0, probably
   named like the others, i.e. net.venge.monotone.monotone-1.0, and
   have that be frozen for changes except for serious bugs.
4. general check that it works on as many systems as possible.

Did I forget something?  Please add to the list.

Cheers,
Richard

-
(*) and please, let's not release it on April 1st...  ;-)

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Contributed scripts and how to handle them...

[CooSoft Support]

What I was referring to as standard Perl, was in the English sense of  
the word and not referring to an ISO standard. I.e. my script will run 
on a basic vanilla install of Perl, what would be got by downloading and 
compiling the tar ball from www.perl.org with default arguments to 
./configure. It doesn't need extra CPAN packages, unlike mtn-browse, and 
is not dependant on multi-threading (an option on ./configure). It's 
just a lot easier to use the word `standard'... :-)


What is available to a Perl script can differ quite dramatically from 
distro to distro. mtn-browse would work out of the box on Mandrake, 
likewise Debian and Ubuntu, but RedHat you would have to download about 
10 CPAN packages. Whereas mtn-cleanup is a much more basic script.


Sorry for the confusion.

Hope this helps :-)

Tony.

Stephen Leake wrote:

Richard Levitte rich...@levitte.org writes:

  

In message 82vd0x4324@stephe-leake.org on Sun, 06 Feb 2011 10:04:35 -0500, 
Stephen Leake stephen_le...@stephe-leake.org said:

stephen_leake I have a beef about people using the word standard in this 
way; is
stephen_leake there an actual ISO or national standard for Perl? Or do you 
just mean
stephen_leake Perl from some normal place, not customized. We need more 
terms for
stephen_leake this. We have international standard, national standard, 
industry
stephen_leake standard. I don't think Perl is any of those? It's just a 
common package.

de-facto standard ;-)



Hmm. That would be for things like Hayes modem commands, or Midi
commands; one company initially dominated, then other companies created
independent implementations of the same command set.

I think there is only one Perl implementation.

So just Perl is enough; no need to say standard.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Contributed scripts and how to handle them...

[CooSoft Support]

Stephen Leake wrote:

CooSoft Support supp...@coosoft.plus.com writes:

  

1) I take it what I need to get up to speed on tests can be found
under the notes directory?



I found it fairly easy just to read the existing tests, and test/*.lua.

  

2) Cross-platform issues, e.g. could I even run diff -r on say a
Windows platform? 



Yes. Compiling monotone on Windows requires MinGW, which provides bash
and gnu coreutils. So just pretend you are on a POSIX system.
  
Excellent - will write the tests accordingly. Interesting about 
requiring MinGW, I thought they used MS Visual studio. Ok will do that 
and if necessary the platform tests can be put in if all else fails. I 
assume that a standard Perl interpreter is included in the Windows build 
environment (that is what the script is written in)?


Many thanks, Tony.
  

Would it be enough to only test on say Linux/Unix/OSX?



No, we officially support MinGW and Cygwin. But that doesn't mean you
have to run tests there. I (and a couple other people) will run the
testsuite on MinGW and Cygwin, and fix/report any problems.

On the other hand, some tests don't work on MinGW; that's what
skip_if(ostype == Windows) is for. It exits a test with a
non-failure status.

Contrib stuff could be limited to non-MinGW, but it would be nice if
that were not the case.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Contributed scripts and how to handle them...

[CooSoft Support]

I nominate mtn-cleanup, not just because I wrote it :-) but it is also 
quite useful especially when used on large source trees ( 900MiB) or 
over NFS. Works with current monotones as well as old ones.


Basically it reverts a workspace to a clean checked out state, doing a 
revertion and then an rm -rf on anything not known to mtn (you are 
warned first).


Also put in a vote for the bash completion scripts (although I think 
they are safe).


Tony.

Richard Levitte wrote:

Sparked by a (somewhat heated ;-)) discussion I had on IRC with Thomas
in late december (*), I've started thinking that the contrib directory, 
while having served us well for a while, might not serve everyone who

wishes to contribute their little nuggets, or have them maintained
separately without having to have write permissions on n.v.m.

Looking at the contents of contrib/, there are things that are aged or
completely superceded by newer monotone commands, or other scripts and
so on.

So, following what Thomas was thinking, we probably should clean out
the contrib directory and put the contents somewhere else, except for
scripts that we really want to ship as part of monotone (and that we
test).  Maybe a place on the wiki would be a start, with a page for
each contributed thing, either refering to a repo somewhere or with
the source directly in the page (similar to plugin contributions that
you can see with other projects).

I'd like to, however, keep the stuff that we use on code.monotone.ca
and the bash completion scripts (I'm about to write a test for it),
and perhaps a few others that are regularly used.  If you have a pet
script in there, please yell, and possibly provide a kind of test for
it.

Ideas are welcome for how the tests should be structured.  For fairly
obvious reasons, lua will not be enough (bash completion testing
requires the use of expect, there's not much lua in there ;-)).

Cheers,
Richard

(*) starting here:
http://colabti.org/irclogger/irclogger_log/monotone?date=2011-01-01#l54

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Contributed scripts and how to handle them...

[CooSoft Support]

Yup happy to do that, only fair after all :-)...

However I am currently knee deep in trying to get mtn-browse to 
efficiently graph revision histories. So mtn-cleanup may have to 
temporarily move to the `dodgier contrib' area for now until I get the 
test script sorted.


When I come to write the lua test script I imagine I would test it by 
creating two pristine workspaces, go into one and change loads of stuff 
without committing and then run mtn-cleanup on it and then do a diff -r 
on both workspaces hoping to find no differences.


Having had a VERY quick look at some other test scripts a few things 
spring to mind:


1) I take it what I need to get up to speed on tests can be found under 
the notes directory?
2) Cross-platform issues, e.g. could I even run diff -r on say a Windows 
platform? Would it be enough to only test on say Linux/Unix/OSX?


   BTW awesome cleanup job :-). Didn't recognise it at first - :-).

   MTIA,

   Tony.
Richard Levitte wrote:

In message 4d4d20fb.6090...@coosoft.plus.com on Sat, 05 Feb 2011 10:05:47 +, 
CooSoft Support supp...@coosoft.plus.com said:

support I nominate mtn-cleanup, not just because I wrote it :-) but
support it is also quite useful especially when used on large source
support trees ( 900MiB) or over NFS. Works with current monotones as
support well as old ones.

Would you be willing to provide a test script?  Since writing my
previous email, I started tinkering, and ended up following the same
form as test/func{-testsuite.lua}, so it should be fairly easy to
produce new tests.  They should end up in test/extra, see recent
commits (test/extra-testsuite.lua and test/extra).

support Also put in a vote for the bash completion scripts (although
support I think they are safe).

That was my first target ;-), and there's a test directory for it
(test/extra/bash_completion) and it's been move to extra/ (to
distinguish from contrib/, which currently holds all untested stuff).

Cheers,
Richard

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[CooSoft Support]

I have probably completely misunderstood but...

If I understand you correctly your multimap would store the raw output 
of the diff. Could one not store the essential arguments to the 
dump_diff() call instead of the diff output (say the two paths and file 
ids but _not_ the file content (which can easily be retrieved when 
needed))? Then iterate through your sorted multimap calling get_data(), 
lua.hook_get_encloser_pattern() and lastly dump_diff(). That way each 
node in the multimap would contain a lot less data than a diff output, 
addressing Richard's concern, and it would also mean that you wouldn't 
have to worry about capturing the output of external diff operations as 
they would be done in order and not require sorting.


Anyway what ever you decide +1 from me as well... :-)

Cheers,

Tony.

Thomas Keller wrote:

I don't say its impossible to do, but it would require quite a lot more
code shuffling. If you look at the actual implementation in
cmd_diff_log.cc, around line 120, you see that we have to keep quite a
lot of state during a potential first round in order to sort things
before we go on with the second round which calculates and outputs the
actual diff.

In the end I'm just up for fixing this one bug, issue 102, so if you
think there is an easier / better way to do it, be my guest :)

Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?

[CooSoft Support]

Works + spanner spring to mind with my reply :-)

Personally I couldn't care less that the au diff command doesn't have 
the --external option and I have never thought it inconsistent as one 
would only use it via some other tool like mtn-browse and if you wanted 
to use say kompare or kdiff3 then it is easy enough for something like 
mtn-browse to do that by fetching the files and doing it manually 
(mtn-browse actually does that).


However on the ordinary mtn diff command I do have --external set up to 
use kompare and that can prove very useful when comparing complex 
unchecked in changes made inside a workspace. Easily got round with a 
script though, automating what Stephen suggested, so certainly not `a 
must have'.


But I must admit I don't see the connection between the question and the 
diff sort order. Wouldn't diff be called per file so isn't it just the 
file order that needs sorting first? Also how does removing it make 
things faster?


In short - no real objections but I think it would be a pity and I can't 
see what it would gain other than simplification. Also other SCM tools 
allow for the integration of external/other comparison tools so may be a 
bit of a negative on the `features' front.


Tony.

Thomas Keller wrote:

I'm working on issue 102 and to make this work properly I want to create
the diff output and return it instead of just printing it to stdout
directly. Problem is that the external diff hook calls execute(diff,
-u, ...) and I wonder if I should go through the hassle and use
spawn_redirected to catch and return the output from there.

One of the main problems is that we have no spawn_redirected
implementation on win32 yet, so --external will fail there. On the other
hand I wonder how many people actually use --external nowadays, given
the fact that we haven't heard many complaints that the internal diff
algorithm produces wrong results compared to diff(1).

Another problem with --external is that its currently also only
available in diff, but not automate content_diff, for much of the same
reason that the diff command plainly prints out the created diff, so
there is this minor incompleteness between both commands.

So, is this a must-have feature or do you think this could be removed
(and simplify and fasten the code at the same time)?

Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] symlink to NFS drive vs update

[CooSoft Support]

   Why not put the whole workspace on the NFS drive? You can still 
control/manage it from your build box. We always use NFS for the 
workspace as we too compile for a variety of platforms. One could change 
Monotone to copy under these circumstances but doing this cross platform 
could be fiddly (as one would have to determine whether target and 
source were on different file systems and would also be very slow 
(copying as against renaming)).


Stephen Leake wrote:

Here's my workspace setup, on a Linux box:

work_stephe
_MTN
build
code_1
code_2
runtime - lynx box/root/runtime

'build' contains makefiles and related files for compiling code. The
compiler is a cross-compiler (from x86 Linux to x86 Lynx OS).

'code_n' contain source code that gets compiled.

'runtime' is a symbolic link to a directory on an NFS-mounted drive on
the Lynx box. For example, suppose 

lynx:/home/stephe/work_stephe 

is NFS mounted to 


linux:/home/stephe/lynx

then 


linux:/home/stephe/root/runtime

is linked to 


linux:/home/stephe/lynx/work_stephe/runtime.

The makefiles compile an executable and copy it to the corresponding
directory on the Lynx drive. When the executable runs on the Lynx box
CPU, it uses files in the 'runtime' directory; those files need to be
under monotone control.

The problem comes when I try to 'update' or 'revert' a file in runtime;
mtn first writes the files to work_stephe/_MTN/..., then tries to rename
to work_stephe/runtime/... , which fails because it is on a different
device.

One fix is to put all the files in runtime into a separate mtn branch,
with runtime/_MTN, but I think that's overkill.

A better fix is to provide a workspace-specific option that tells mtn to
use a different staging area for files in runtime. For example, in
_MTN/options:

tmpdir runtime runtime/tmp

The user would presumably add runtime/tmp to .mtn-ignore.

This would be passed to file_io.cc:write_data as a map; write_data would
search the map for a matching prefix of the directory being written to.
In the typical case of no 'tmpdir' in _MTN/options, the map would be
empty, causing no speed impact.

Other ideas?

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] viewmtn status

[CooSoft Support]

   Yes in Jan this year the au stdio i/f changed in 0.46 to have 
additional I/O streams. This also affected the existing I/O stream 
format that was already there.


   Tony.
Brian May wrote:

Hello

Is viewmtn still maintained? Still working?

I am having problems, it seems that it receives the data it expects
from mtn stdio, and then blocks forever on a select statement.

I tried running the same stdio automate calls by hand and they seem to
work fine.

Later:

hmmm... Looks like this regexp is broken:

packet_header_re = re.compile(r'^(\d+):(\d+):([lm]):(\d+):')

which is expected to be parsed as cmdnum, errnum, pstate, length = m.groups()

The data returned by mtn stdio is:

0:m:40:au.com.microcomaustralia.website.themes
0:l:1:0

So I think maybe the format of stdio has changed since viewmtn was last updated.

This is on a Debian squeeze system.
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Release Of Monotone::AutomateStdio For Monotone 0.99.1

[CooSoft Support]

   Just to say that release 0.10 of Monotone::AutomateStdio that 
supports Monotone 0.99.1 is now available for download at:


   http://search.cpan.org/perldoc?Monotone::AutomateStdio

   For those mtn-browse users amongst you, you can simply untar the 
package and drop the contents of the lib/monotone directory into place 
and your copy of mtn-browse should work with mtn 0.99.1.


   I will be working on a new release of mtn-browse that will support 
the new selector functions.


   Tony.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] A Few Quick Questions...

[CooSoft Support]

Richard Levitte wrote:

In message 4cfa33ad.4090...@coosoft.plus.com on Sat, 04 Dec 2010 12:27:25 +, 
CooSoft Support supp...@coosoft.plus.com said:

supportFirstly if I want to update the wiki exactly what db do I
supportuse and branch, I can't find anything to do with wikis in
supportany database that I can browse... Also if I don't have
supportwrite access to it can I be granted write access please.

Have you tried registering on the wiki itself?  Editing is mainly done
directly, not via external commits.  As for the database itself, it's
only available to 3 people (myself included), for maintainance
purposes.
  

Are ok many thanks for that...

supportSecondly I have been meaning drop a copy of mtn-cleanup, a
supportscript that reverts a workspace to its freshly checked out
supportstate into monotone's contrib dir. Unfortunately I have
supportbeen tied up with the Monotone::AutomateStdio stuff until
supportnow. I noticed that Richard was having a cleanout of the
supportcontrib area. 1) would people find such a script useful
supportand 2) am I too late for the 1.0 release? (It is a
supportstandalone script that makes use of mtn au
supportget_manifest_of, so that is one perl script in the contrib
supportdir, updates to readme files and an entry in the news
supportfile).

I suggest you register yourself an account on code.monotone.ca.  When
you've done the basic registration, go to your account (click on your
name in the upper right corner), then click Update your account and
add your monotone key in Add a public key.  When done, email on
monotone-devel and ask someone to add you as a member of the monotone
project.  Or do that on the IRC channel.

Cheers,
Richard

  


Sorry for the confusion, I do in fact have an account, have write access 
to the monotone db and my two projects. Really the question was one of 
any objections to me checking in the script into the contrib dir at this 
late stage (since I'm mainly pre-occupied with Monotone::AutomateStdio 
and mtn-browse I hardly touch the main monotone branch and didn't want 
to step on any toes). I guess from the above though that it would be ok.


Cheers,

Tony :-).

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] mtn au checkout - Possible Issue...

[CooSoft Support]

   Hi all,

   Just been testing the Monotone:AutomateStdio Perl library against 
0.99.1.


   As a part of the testing I tried using the new the au checkout 
command. During the entire test (which exercises all of the au stdio 
interface) the mtn subprocess is not terminated (so the same instance is 
used to test all commands) and the same dedicated test workspace is used 
(which is reset after each test run).


   The checkout test was basically run inside this test workspace and 
the equivalent of `au checkout --branch net.venge.monotone 
../MTN-TESTER-WS' is done (i.e. it is checked out at the same level as 
the current test workspace and not inside it). When that test has 
finished the ../MTN-TESTER-WS directory is removed. From then on in, 
despite being in the original, untouched test workspace, every command 
fails with a `I need a workspace' error. If however, I restart the mtn 
subprocess directly after this test then everything works as expected.


   It is as if the au checkout command changes the mtn subprocess's 
notion of what workspace it is using, and then gets very upset when it 
can no longer find it.


   I'm not quite sure if this is intentional or a bug. I think it's a 
bug but there may be a very good reason why this is done. I can 
understand why it needs to temporarily switch workspaces, but shouldn't 
it switch back again afterwards? If it is a bug then let me know and 
I'll raise a ticket.


   Cheers,

   Tony.
Thomas Keller wrote:

Am 26.11.2010 16:23, schrieb Hendrik Boom:
  

2) the wiki is in a horrid state and the manual could need some cleanups
as well (e.g. moving stuff like the long discussions at the end and
other smaller things). as the response on my Road to 1.0 mail was
rather low and we all don't like to do these things on our own I am for
holding another mini sprint, i.e. one full or two half days, depending
on the feedback, this time called docathon because of the emphasis on
documentation. we should roughly team up beforehand though so that we do
not end with an inconistent result at the end.
  
I'd like to help with the documentation.  If it's a matter of 
reorganising what's already there, cleaning up awkward phrasing, 
making things less obscure than the are already (provided I know 
what needs to be said) I can certianly help.


If it's a metter of providing information that's not there at 
the moment, I can't say I can help; most of my knowledge of 
monotone comes from the documentation, and what's not there is 
not there.


But I can draft best guesses that might be of use to beginners, 
subject to complaints by those who really know the stuff.



We need a lot of first user documentation, for example monotone for XXX
users where XXX is one of git, mercurial and svn (at least). We have
a mtn for cvs users part in the manual, but I'd like to move that out
there and put it into the wiki to the others. This is just an example,
there are other first user docs needed as well.

So, as a proficient user you are the perfect match to work on the
documentation and your work is very welcome! :)

  
I am not available in November, though. 



We have to find a matching date before anyways and its unlikely that
this will be in November, so no problem at all.

  
I'll probably have to 
register in some way with the wiki or the central monotone 
repository, though.  Where and how do I do that?  I gather the 
details have changed recently.



If you want to edit the wiki, you can do so online (register an account
and start editing) or offline via monotone.

For the latter register an account on code.monotone.ca and put your
public key there. Once you've done that drop me a note and I'll add you
to the appropriate project (monotone-web) for push access.

Thanks,
Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: Fwd: Re: [Monotone-devel] Updated Issue 109 - mtn au get_extended_manifest_of Should Default To Current Workspace Like get_manifest_of Does (monotone)

[CooSoft Support]

Sorry for the delay. I have been in bed with the Flu :-(. I have taken 
the liberty of moving the ticket into wont-fix to save any more time 
being wasted on it.


Many thanks for your feedback...

On another note I was in the process of updating Monotone::AutomateStdio 
to the new features of 0.99.1. Are there any other au commands scheduled 
for 1.00 that weren't included in 0.99.1 that I should know about :-)?


Also there is something that I have been meaning to ask about selector 
functions WRT mtn-browse. In mtn-browse I provide a drop down of all 
selectors that can be used and also describe/prompt for their arguments. 
I vaguely remember reading somewhere that new selector functions could 
easily be defined and used (presumably in LUA). Is it the case that a 
user could have their own selector functions? If so how could I get a 
list of these functions from the command line or config file? If it's 
the case that they are built into mtn like the single letter selectors 
then that's fine I'll just hardwire it like before.


Many thanks in advance,

Tony.

Thomas Keller wrote:

Forwarding this to the list...

 Original-Nachricht 
Betreff: Re: [Monotone-devel] Updated Issue 109 - mtn au
get_extended_manifest_of Should Default To Current Workspace Like
get_manifest_of Does (monotone)
Datum: Sun, 21 Nov 2010 13:27:17 -0500
Von: Stephen Leake stephen_le...@stephe-leake.org
An: c...@monotone.ca

  

109 - mtn au get_extended_manifest_of Should Default To Current
Workspace Like get_manifest_of Does



  

# By Thomas Keller, Nov 20, 2010:



  

The result is a compromise - have one (extended) format for committed
changesets and use inventory for uncommitted / workspace changesets.
We can easily add more fields to inventory from the roster if needed
(right now the most prominent recent addition was the birth revision
stanza), but I'd do that on individual request.



  

# By Stephen Leake, Nov 20, 2010:



  

In general, automate commands don't have default arguments. The design
is that automate commands are used by front-end tools, which can
easily provide all the required parameters.



Given the above, I think we can mark this issue won't fix?

-

Lets wait for the feedback from Tony and then act accordingly. won't
fix sounds reasonable.

Thomas.


  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Project separation

[CooSoft Support]

Lapo Luchini wrote:

Thomas Keller wrote:
  

I already brought up the idea on IRC some time ago - I am looking for a
way to restrict allowed incoming revisions on the server-side.



I've got an idea, which might well be orthogonal to yours (or be the
same, really?), but could have some use: by default use the branch
filter only to find the root of the graph, and then bring it all.

Right now we have a (huge) graph spanning over some 30 branches but,
since most of them are merged in mainline already, in fact pulling
nvm-only *already* brings in the bulk of most of those branches,
*except* the branch certificate.

This way they're not polluting the mtn ls branches (which is good) but
OTOH we're really liars about that, because we *already* have 99.9% of
the bload of those branches, with the only exception of the name.

We might thus (as an option, or by default) mean pull nvm as pull the
ROOT element which was named 'nvm' plus all of its children, in any
branch whatsoever.

OTOH if some feature branches are adding huge files and then deleting
them before mainline landing, we're probably *not* pulling that bulk
right now; but I wonder how often does that happen in a fairly
well-behaved project.

  
Hmmm just a thought... But at work we are using 0.39 (can't use a later 
version as the schema changed and the latest monotone-viz just runs too 
slow (pre 0.40 one could use the direct access to db version of 
monotone-viz)).


Anyway we have about 18k revisions, 10k tags and about 4k branches 
(guess from memory). Doing a full sync on the entire db with no changes 
to propagate takes about 10mins. However if you just sync the release 
branches (~200 branches) then that takes about 15 seconds but as Lapo 
says pulls in about 99% of the branches just not their certs.


I know I know :-) that was 0.39 and quite frankly unless you are the 
build manager, why pull in all branches? But something to think about 
unless this has changed in the more recent versions of mtn.


As I said above the choice of 0.39 is not going to change in the near 
future for that team but I will, just out of interest, set up my own 
server with 0.99.1 migrate across and then get some timing figures and 
post them here as this point could now be a red herring.


Tony.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Project separation

[CooSoft Support]

Lapo Luchini wrote:

CooSoft Support wrote:
  

Hmmm just a thought... But at work we are using 0.39 (can't use a later
version as the schema changed and the latest monotone-viz just runs too
slow (pre 0.40 one could use the direct access to db version of
monotone-viz)).



I wonder how much would it take to update the direct access code; the
schema has changed, but not *that* much... but you're using a pre-1.0
monotone-viz, I guess, or is direct access still in there, just not used
by default?
  
Yup pre 1.0. I remember thinking `oh great that means I won't have to 
recompile it again etc'... until I ran it up... :-(. Presumably all it's 
doing on the mtn front is a graph and then querying the revisions to get 
certs etc, neither of which are slow (mtn-browse can do 1000's of 
revisions in a few secs). Trouble is it is written in Ocaml and it is 
completely impenetrable, to me at least, otherwise I would have had a 
good look and found out what was causing the issue. I thought it might 
be that the mtn subprocess was restarted on each call but apparently 
that is not the case.



Anyway we have about 18k revisions, 10k tags and about 4k branches
(guess from memory). Doing a full sync on the entire db with no changes
to propagate takes about 10mins. However if you just sync the release
branches (~200 branches) then that takes about 15 seconds but as Lapo
says pulls in about 99% of the branches just not their certs.



10 mins versus 15 seconds? Wow! 0_o
  
I'll do some timings - remembering how long you wait for something is 
very subjective... Especially if you are in a hurry!


Cheers :-)

Tony.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Release Of mtn-browse 0.71

[CooSoft Support]

   Just to let you know the above version of mtn-browse has just been 
released and provides support for mtn version 0.48 (supports changes 
made to the diff output) and has a few minor bug fixes.


   You can download and look at the release notes/news from here:

   http://sourceforge.net/projects/mtn-browse

   Regards,

   Tony.

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] changelog editor issues

[CooSoft Support]

Stephen Leake wrote:

The only task remaining on the RoadMap [1] for 0.99 is the changelog
editor issues.

I've read thru the email thread [2]. There is overwhelming support for
moving the changelog comment to the top, possibly with a small header.

Francis Russell suggested a format [3] that several other people
seconded:



*** MODIFY OR REMOVE THIS LINE TO CANCEL THE COMMIT ***
--Edit fields beneath this line to modify certificate values--
Branch:   uk.co.unchartedbackwaters.simple_cfd.tensor.expr.cse
Author:   Francis Russell example at example.com
Date: 21/07/10 13:35:29

--Modifications under this line are ignored entirely--
Changes against parent bd846e89bef8324b758f8a2c6e7dde41aa4ddd9d

  patched  include/simple_cfd/cse/cse_optimiser.hpp
  patched  include/simple_cfd/numeric/ginac_expression.hpp

  
Possibly have a -- ... --- style entry telling the user where to put 
their changelog message?




--Enter a description of this change above--
*** MODIFY OR REMOVE THIS LINE TO CANCEL THE COMMIT ***
--Edit fields beneath this line to modify certificate values--
Branch:   uk.co.unchartedbackwaters.simple_cfd.tensor.expr.cse
Author:   Francis Russell example at example.com
Date: 21/07/10 13:35:29

.
.
.
Just a thought...

There was discussion of whitespace trimming; with this format, only
trailing blank lines need to be trimmed from the commit comment.
  

Thank you :-)
+1

There was a suggestion that the signing key could be different from the
author; this is possible on the command line, but not in this editor
format.

There was a suggestion to allow editing the changelist section, to
exclude files from commit (similar to the --exclude command line
option). That is complicated; let's leave that for later, or at least in
a separate discussion.
  

That is a great idea :-). Certainly would get my vote if/when it is done.
+10 :-)

I propose that we adopt this format, with the addition of a 'key: '
line under the 'Author: ' line; any objections?
  

+1

Derek; do you have time to work on this? I can do it if not.

[1] http://www.monotone.ca/wiki/RoadMap/
[2] http://thread.gmane.org/gmane.comp.version-control.monotone.devel/17851
[3] http://thread.gmane.org/gmane.comp.version-control.monotone.devel/17936

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] No sponsored hardware :(

[CooSoft Support]

Same here also... :-)

Tero Koskinen wrote:

Hello,

On Mon, 23 Aug 2010 14:54:20 +0200 Thomas Keller wrote:
  

Hi!

I was just notified that we didn't made it into the top 5 projects and
unfortunately got no hardware price from Thomas Krenn:

Is anyone here on the list which could offer us a Xen instance on his
physical server?

If not, who is willing to throw in some money to buy a server?



I can donate some modest sum. Although, does the Monotone project
have some money already?

I remember njs speaking about it a few years ago:
http://www.mail-archive.com/monotone-devel@nongnu.org/msg05877.html

  

Opinions and / or alternative offerings?



There is always Linode, but I don't know does it have as good
performance/money ratio as Netcup.

If we end up buying a VPS for the project how we handle all
the maintenance things? Do we need to care about the bus factor
of the maintainer(s)? (What happens if you get hit by a bus,
spend ten years in a coma, and we need to renew the VPS
subscription?)

And how the collection of money happens? Wire transfers
inside Europe are free (thanks to SEPA), but people outside
Europe might prefer other ways.

  

Thanks,
Thomas.



  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] 0.48 rants

[CooSoft Support]

Derek Scherger wrote:

Starting a series of replies...

On Sat, Jul 17, 2010 at 1:40 AM, CooSoft Support 
supp...@coosoft.plus.com mailto:supp...@coosoft.plus.com wrote:


I'm not currently using 0.48 and from what I hear nor will I. I to
want comments to go in unmolested and not have white space
stripped out. For me that is a must.


I've found that I have commits with random amounts of trailing 
whitespace (newlines) and that's the entire reason that for the 
trimming. I think Lapo mentioned that he had similar concerns about 
how much whitespace would precede or follow his commit message and the 
basic idea was to allow people to stop worrying about such things.


Point taken though, perhaps this trimming should be restricted to 
leading/trailing newlines and perhaps it should also be configurable 
by a hook so that can be controlled.


I personally have no issue with trimming blank lines at the beginning or 
at the end of a commit message and like you agree that is better than 
not doing it. But non-whitespace lines and blank lines in the middle of 
a commit message should be preserved as is (with the exception of blank 
lines as they could have any spaces and tabs removed).


Why are date and author changeable? Surely these should be
immutable (apart from one could specify an alternate key on which
to perform the checkin - I assume that the same restriction
applies when changing the author in the changelog (i.e. you have
to have a private key for that user in your keys directory).


They're changeable in the editor exactly  because they are changeable 
on the command line with --date, --author and --branch arguments and 
for no other reason.


Ok sorry - it has never occurred to me anyone would want to do this. 
Point taken.


I also agree that the changelog that the user enters should go at
the top. When working with GUIs you quickly learn that trying to
slow a user down and make him/her think about the consequences of
what they are about to do is mostly a waste of time as they simply
get used to clicking on that extra button or in this case
scrolling down x lines...


There was *absolutely* no intent of slowing anyone down with this. It 
was about allowing review and changes and unifying the various 
randomly different output formats. Configuring your EDITOR with +N 
should allow the leading lines to be skipped.


Cheers,
Derek



When I meant slow them down it was in the context of getting them to 
review and reflect on what they are doing before doing it. I still think 
this will be met with resistance. However, having a simple generic 
setting, that when set in the config file, will automatically move the 
editor the required number of lines to the entry point should counteract 
any resistance. Doing EDITOR= +n14 is a bad idea as many other 
programs use this. Perhaps do this move 14 lines down stuff by default. 
Just a thought.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] 0.48 rants

[CooSoft Support]

I'm not currently using 0.48 and from what I hear nor will I. I to want 
comments to go in unmolested and not have white space stripped out. For 
me that is a must.


Why are date and author changeable? Surely these should be immutable 
(apart from one could specify an alternate key on which to perform the 
checkin - I assume that the same restriction applies when changing the 
author in the changelog (i.e. you have to have a private key for that 
user in your keys directory).


I also agree that the changelog that the user enters should go at the 
top. When working with GUIs you quickly learn that trying to slow a user 
down and make him/her think about the consequences of what they are 
about to do is mostly a waste of time as they simply get used to 
clicking on that extra button or in this case scrolling down x lines...


Francis Russell wrote:

I was intending to write about the new commit template stuff too. Having
the commit message in the new location has significantly increased the
effort and time which it take me to make a new commit. I considered
downgrading back to 0.47 just to avoid it. I really feel that I
shouldn't have to memorise the fact that the 'Changelog:' token is on
the twelfth line. In addition, the new white-space handling is a pain. I
sometimes like to use commit messages of the form

 - item1
 - item2

but the parser swallows any initial whitespace so I can't indent the
first line.

I also feel the template bombards me with information that I already
know or don't really care about when all I want to do is type a commit
message. I don't need to read a help message on how to edit the
changelog and other fields every time I commit and I can't imagine what
anyone might learn from the parent revision or current revision hashes
that they didn't know before they decided to commit.

I'm all for displaying the author, date and branch in the footer as
these are user-editable modifiable values that they could conceivably be
wrong. In particular, I've often committed to the wrong branch without
realising it but I feel adding a second mechanism to edit these just
duplicates functionality and adds the complexity of a parser. I suspect
most monotone users are reasonably sophisticated people who don't need a
meta-interface to edit values they could already have specified on the
command line though others may disagree.

Francis

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: is monotone for me?

[CooSoft Support]

   Yup that is an understatement - one of the reasons why I was 
attracted to the project... When the biggest cause of corruption seems 
to be faulty RAID hardware then you know that you are onto a winner.


   I did some tests, with the aide of one of the developers, to 
simulate corruption (I was worried about faulty desktop disks corrupting 
other databases on sync). It was damn difficult to get it past the local 
mtn process without it detecting it and then pretty much impossible (I 
never got it to sync with a corrupted db - but very difficult to prove a 
negative etc) to get it past the sync stage :-).


hend...@topoi.pooq.com wrote:

On Mon, Jun 28, 2010 at 10:41:50PM +0100, CooSoft Support wrote:
  
It has proved to be 
totally reliable



That's for me is the most important thing about monotone, trumping all 
other considerations.  The monotone developers are more paranoid about 
data loss than I am.


-- hendrik.

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: is monotone for me?

[CooSoft Support]

   Sorry if this has been mentioned before. I used to run mtn on a 
SPARC server at work. The database was 1.5GB ~5 revisions ~3000 
branches and ~1 tags. It was very easy to set up and maintain. It 
pretty much ran itself. The server had 4GB of memory and it never got 
close to using that (maybe ~1GB during a big sync). No issues really. 
Sync performance could be slow but that is related to the number of 
branch tags you sync against and not the number of revisions. I used to 
keep up to date on the release branch and that would check and sync 
~45000 revisions in 15 or so seconds (on SPARC hardware so not high 
performance). It has proved to be totally reliable and other areas are 
looking into possibly using it. It has got a very clean cli and most 
tools are available cross platform (and we have used these as well).


   Incidentally they are still happily using monotone, but I have moved 
jobs and hence the past tense above! :-)


   Cheers,

   Tony.
Gour wrote:

On Sun, 27 Jun 2010 14:57:25 +0200
  

Thomas == Thomas Keller m...@thomaskeller.biz wrote:
  


Thomas Have you ever tried ikiwiki? This is a nice and very expandable
Thomas (plugins) wiki engine which comes with support for different
Thomas SCMs, amongst them monotone. 


Nope, but weas reading about it...

Thomas Basically texinfo, what Stephen said, with lots of custom
Thomas hacked CSS from me to make it pretty :)

Heh, it really does not look like common texinfo stuff. :-)

Thomas Well, I can't exactly say if monotone is the right tool for you
Thomas - as others said it works good for medium-size projects, but
Thomas can be slow for particular use cases, like very big trees (tens
Thomas of thousands of files) and many, many concurrent users. 


We won't most probably have such a project.

Thomas But we're actually still want you to test it out if it works,
Thomas because you have a very good and easy exit strategy with our
Thomas fast export to git, which is understood by other SCMs as well.

:-)

I'm more interesting for enter stategy. ;)

Thomas We discussed that here over and over and basically it was some
Thomas kind of generation change, the original developer(s) left the
Thomas project, probably also a bit overrun by the tremendous success
Thomas of git, and a few people who kept loving this SCM kept around
Thomas and tried to start anew. The community is small and the amount
Thomas of active developers is even smaller, but thats the classic
Thomas vicious circle, not many users will not lead to many patche -
Thomas still, we fight and continue to fight on all fronts as time
Thomas permits.

How many devs are actively working on mtn?

It seems people should become burnt with Git before looking for
alternatives.

Thomas I guess in the (near) future indefero (http://indefero.net)
Thomas will also offer monotone hosting. I'm currently just waiting
Thomas for my patch [0] to get included in their trunk, which should
Thomas happen within the next couple of days.

Great news!

Thomas I have a monotone server running on a small-sized VPS with only
Thomas 200MB fixed RAM and the ability to boost that to 600MB, and I
Thomas have many other memory hogs on this system as well
Thomas (spamassassin f.e.). The server works quite well and fast -
Thomas though it only serves a couple of smaller branches, one of them
Thomas being guitone.

Not bad. Maybe I should try to install some repo on my WF account and
check it out.

Still, indefero option sounds great. ;)

Thomas I'm the author of guitone and I'd say the recent versions
Thomas should be very well capable of replacing the CLI indeed (after
Thomas all guitone is targeted at exactly your envisioned user group).

Wonderful!

Thomas I'd love to get some earlier feedback
Thomas from you on guitone though, so I'd be happy if you try it out
Thomas before it hits 1.0 :)

I created package for Archlinux and installed. Now I need to learn
more about mtn and then I'll put guitone to some more serious testing
providing you with (hopefully) some valauble feedback.

Thanks a lot for your input.


Sincerely,
Gour

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Release time

[CooSoft Support]

Thomas Keller wrote:

Am 28.05.2010 15:07, schrieb Philipp Gröschler:
  

On 28.05.2010 10:23, CooSoft Support wrote:


I couldn't agree more with Thomas's point about Monotone dying if we are
not careful. It's a psychological thing. `Oh it's only at 0.xxx - still
unstable'.
  

Sure it's psychological and nowadays in the age of OSS, versioning
schemes or rather the progress of their numbers are often not really
expressive. Wine took 10 years to release 1.0 and noone really cared in
the end, because it has been working for ages before. On the other hand
I've seen software for example in a 5.x version and was hugely wondering
what that thing did the four major versions before.



Absolutely right, I don't want to increase the major version every few
months from now on either, but I also don't think we should follow
Wine's example here. Six years are enough :)

  

People shouldn't look at the numbers of the version but rather on the
feature list on the project's website. Maybe somewhere on that website
there should be included a sentence like We use it all the time and no
problems so far. Like Jack, I personally use Monotone for all my work
stuff, source codes, server configs, etc. My lady is using Monotone for
her thesis. No problems ever, so count that as +2 from here :-)



Tony mentioned some praise as well, and hey, we even have a dedicated
wiki page to add this:

http://monotone.ca/wiki/Testimonials/

So don't be shy and add your comments there - I'll happily link this
wiki page on the front page!
  
Lol - I have some time ago. I was the one responsible for the gushing 
`look no further' comment at the bottom. Sorry, I was just feeling 
emotional at the time - lol :-). Our SDA was I think responsible for the 
11 year old CVS code base one (although he is keeping quiet about it!). 
Hehe.
  

One problem of a 1.0 or 1.0.0 release could be, that the more
sophisticated users from bigger development groups, which then start to
use monotone because of the major release, often stick to a version they
chose in the beginning of a project. Of course they still want to have
bugfix releases, but by no means they want breakage in the API or
interface or whatever applies.

I've seen this happen on another project I accompanied a while ago. As
soon as they put out 1.0 there only came bugfix releases afterwards,
although many requests for mostly the same improvements appeared on the
mailing list and the excuse always was like No we don't do that,
because then we would break with the big guys. Does Monotone have the
power to support two branches, so that new and needed features don't get
stalled?



For that to happen we'd need to have more of these big guys in first
instance - and I'd love to support them all. From a management point of
view I don't care if I handle one single branch or two, a stable and a
feature branch, or whatever works for them.

Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Release time

[CooSoft Support]

Philipp Gröschler wrote:

On 28.05.2010 10:23, CooSoft Support wrote:
  

I couldn't agree more with Thomas's point about Monotone dying if we are
not careful. It's a psychological thing. `Oh it's only at 0.xxx - still
unstable'.



Sure it's psychological and nowadays in the age of OSS, versioning
schemes or rather the progress of their numbers are often not really
expressive. Wine took 10 years to release 1.0 and noone really cared in
the end, because it has been working for ages before. On the other hand
I've seen software for example in a 5.x version and was hugely wondering
what that thing did the four major versions before.
  

IMHO

I agree that's how techies work, oooh looks cool I'll give that a spin. 
But, and pardon me for saying this, SCM systems are the sort of tools 
that techies don't get too excited about generally, and just want 
something that works and is reliable, and so may only look more 
superficially because they want to get back to doing `cool stuff'. Also 
the dreaded management peeps stick their oar in and start going on about 
trusting our crown jewels to `something that isn't formally released 
yet'. I had to fight for about 6 months on and off to keep the 
management off our backs otherwise we would have been forced to use 
ClearCase. It would have been easier to convince them of mtn's stability 
if it was at 1.x rather than 0.x. I know, silly, but we are talking 
about management after all.


Your point about version 5.x and wondering reminds me of TopCased. It's 
at version 2 and as stable as a Jenga tower! Makes me wonder what 1.x 
was like :-(.


Point taken about 1.0 forcing you to not break things. Changing schemas 
is no biggie, easy for a user to cope with, db migrate or sync. CLI is 
unlikely to change that much (at least I hope not) as that is one of its 
many selling points. CVS/SVN users can virtually use it straight away 
(unlike GIT), even ClearCase users (mind you they are usually so 
thankful not to be using ClearCase).


au stdio, hopefully will mainly be additive from now on (I hope! - lol).

As for feature freeze. We have had to do that for our software. We 
currently have ~10 release branches and develop on the latest version 
whilst supplying patch fixes to 8 year old releases. That's why we love 
Monotone, it makes it so easy :-). Comes with the territory of doing 
something people want I'm afraid.

People shouldn't look at the numbers of the version but rather on the
feature list on the project's website. Maybe somewhere on that website
there should be included a sentence like We use it all the time and no
problems so far. Like Jack, I personally use Monotone for all my work
stuff, source codes, server configs, etc. My lady is using Monotone for
her thesis. No problems ever, so count that as +2 from here :-)
  

Agreed but some peeps do :-(

One problem of a 1.0 or 1.0.0 release could be, that the more
sophisticated users from bigger development groups, which then start to
use monotone because of the major release, often stick to a version they
chose in the beginning of a project. Of course they still want to have
bugfix releases, but by no means they want breakage in the API or
interface or whatever applies.

I've seen this happen on another project I accompanied a while ago. As
soon as they put out 1.0 there only came bugfix releases afterwards,
although many requests for mostly the same improvements appeared on the
mailing list and the excuse always was like No we don't do that,
because then we would break with the big guys. Does Monotone have the
power to support two branches, so that new and needed features don't get
stalled?

Just a few thoughts :-)

Philipp

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Release time

[CooSoft Support]

One slight deviating point about breaking BC with au stdio... I feel 
what ever applications we provide that use it should strive to cope with 
BC breakages. E.g. Monotone:AutomateStdio works from 0.35 to the current 
release as does mtn-browse which relies on it.


Hopefully though with the changes made recently to stdio, future changes 
will be additive :-) (fingers crossed).


Why did I go to this effort? Apart from the obvious it was also because 
at work they are on version 0.39 of mtn as any higher breaks the `direct 
access to db version of monotone-vis', the later au stdio version of 
monotone-viz for some unknown reason runs MUCH slower on our db, too 
slow to be of any use :-(. Other companies/people may have similar 
issues. And monotone-viz is one of mtn's killer apps...


I like the idea of attaching a specific significance to a change in 
major/minor/patch level number. Makes it much clearer for the user.


Tony.

Ethan Blanton wrote:

Derek Scherger spake unto us the following wisdom:
  

1) if a release only consists of bug fixes or has small, not BC-breaking
improvements (esp. in respect to automate), raise the patch release

2) if a release has bigger improvements or breaks BC, raise the minor
version

3) if a major flag day introduces major new things or we've rewritten
90% of monotone (:)), raise the major number.


  

I think that pretty much agrees with
http://apr.apache.org/versioning.htmlwhich is referenced by various
other projects.



I'd modify this somewhat, for monotone, because *network*
compatability is quite possibly its most visible feature.  Perhaps
something like:

Major version bump - netsync incompatability (or major features you
  don't want people to miss)
Minor version bump - database upgrade required (or ...)
patchlevel - bug fixes, minor changes, user can upgrade
  without concern toward databases or
  interoperability

This is along the lines of typical library versioning, with minor
versions indicating link-compatible changes, and major versions
requiring relinking.  (The binary compatability prose in the Apache
page above.)

That said, versioning is *way* bikeshed.  Everyone has their own
opinion on how it should be handled.  I think the important thing here
is to pick *something* meaningful and stick to that meaning.

Ethan

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Release time

[CooSoft Support]

I couldn't agree more with Thomas's point about Monotone dying if we are 
not careful. It's a psychological thing. `Oh it's only at 0.xxx - still 
unstable'. We have all done that at some point when looking at rival 
projects as an end user in a hurry to get something up and running. It's 
only if something catches our eye that we change our mind - with mtn it 
was the documentation.


When choosing a new SCM system our SDA recommended Monotone but asked a 
few of us to look into the subject. Like most people I was unhappy about 
trusting something at version 0.34 with storing our 11 year old CVS 
based project. But I trialled out both mtn and git. Apart from agreeing 
that mtn was definitely the way to go (much cleaner design, everything 
worked as documented, good clear documentation and interface etc), the 
only thing that puzzled me was the version. It was more like 3.4 and not 
0.34. We now have a db ~ 1.5GB, 20k revisions, about ~1K branches and 
~8K tags and going strong.


When giving monotone presentations and demos the most common question is 
about it being beta software at version 0.xx...


To not go to 1.x in the very near future will be monotone's death 
sentence, it's probably already too late thanks to GIT. I really hope 
I'm wrong about this as I want the better product to win...

Am 27.05.2010 18:54, schrieb Jack Lloyd:
  

On Thu, May 27, 2010 at 09:38:32AM +0200, Thomas Keller wrote:



Apropos release - a fellow developer reminded me that we *might* want to
set a proper release number for the next release (you know what I'm
talking about, 1.0...) - given the fact that we're still recognized as
alpha software in a couple of places. What do you think?
  

Just for the sake of argument:

While 1.0 is good for a public image perspective, is it something that
you want to lock yourself into?

I can think of a few things that might potentially happen that might
be harder to pull off post-1.0:

 - s/netxx/asio/

 - netsync over TLS

 - policy branches (or some equivalent change; mtn's inability to do
   proper per-branch security is actually a big problem for me - it
   makes me nervous giving out write access to public projects,
   because while I'd be fine giving some random person write access to
   some particular subbranch that I could pull changes from, I
   wouldn't want them to be able to scribble elsewhere, even by
   accident. Limitations in this area also make me nervous about
   putting branches that have to remain private/secure on my public
   mtn server).



Other people already responded here, just my 2 ct:

I've just recently stumbled across your TLS feature request in the
tracker from 2006 and simply put, if there was just not enough man power
to do that until now, I don't think it will happen until 1.0 either (if
1.0 should be out this year or beginning of next year). The same is true
for policy branches (which recently saw more development though, thanks
to Tim) and the replacement of netxx (what we should not only do for
cosmetic reasons, but also for better IPv6 support).

My main point is: We need more users! More users means more development
(directly because of feedback and eventually indirectly because of more
submitted patches). And I fear that if we only ever think in small steps
and improvements like in the years before, this project will probably
die off in the future silently because it won't get noticed and fewer
and fewer new people will hack on it. This is why I started to blog more
about monotone in my personal blog and why I syndicated it on monotone's
home page. To generate more more interest, more buzz, more traffic.

After all we should all agree that monotone has been proven stable for
many, many versions now and that we (the original and today's
developers) should be proud of it, so proud that we should dare to put a
proper version label on this darn thing.

Jack, don't get me wrong, all the above mentioned features are surely
important (and I'd love to see them implemented), but I don't think they
should block 1.0 any longer.

  

BTW, a minor suggestion: if the next release is 1.0, perhaps this
would be the time to switch the versioning scheme? 1.0 implies
stability, so people will be surprised if there are major changes
between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala
Linux kernel would make it easier for users to see which were small or
bugfix releases (1.0.4-1.0.5) and which were larger (1.0.5-1.1.0).
(OTOH one could represent larger changes by going to 2.x, 3.x, ...  as
well, so I suppose this is a bit of bikeshedding)



I agree that continueing the current versioning scheme, just with a
prefixed 1., won't make much sense any longer, but I'm against
complicating this too much. A new easy rule for now could be:

1) if a release only consists of bug fixes or has small, not BC-breaking
improvements (esp. in respect to automate), raise the patch release

2) if a release has bigger improvements or breaks BC, raise 

Re: [Monotone-devel] Release time - au stdio update

[CooSoft Support]

   Sounds like a great idea to me, especially the 1.0 bit :-)).

   However one minor point about the impending release (what ever 
version it may be) :-(...


   I was looking at the changes for the next release and noticed the au 
update command. Great, but why does it's progress messages go out on 
stderr, should that not go out on stdout in the normal output stream 
(possibly in stanza format)? It would be nice if it were consistent with 
other au stdio commands as most things using au stdio treat output on 
stderr as indicating a problem.


   The main issue is where the output goes. As for free format text vs 
stanza I'm happy to leave that to people better qualified to judge the 
merits of that point.


   If this could be fixed before the next release that would be great 
as I would like to avoid putting in nasty `read stderr until no more 
data and redirect to normal output channels' exception code for one 
command into Monotone::AutomateStdio for the sake of one release (this 
library completely supports all au stdio commands in versions of 
Monotone 0.35 up to and including 0.47).


   Happy to raise a bug ticket if this is deemed acceptable.

   Tony.

Hi all!

As I've announced earlier I'd like to start the machinery for the next
monotone release now that the database management branch has landed. So
if you have anything you'd also really like to see in the next monotone
version, please finish it up and merge it into mainline (I remember we
still have a couple of open bugfest branches, right Derek and Richard?),
because I'd like to give the translators a chance to work on a stable
i18n source.

Apropos release - a fellow developer reminded me that we *might* want to
set a proper release number for the next release (you know what I'm
talking about, 1.0...) - given the fact that we're still recognized as
alpha software in a couple of places. What do you think?

On the upside is for me that we have tons of bugfixes and a nice set of
new features, so it should be a sound release. On the downside is I
think that there might be a couple of rough edges which people would
like to see fixed before a 1.0 happens. I don't see many of these edges
though and the ones I see are open for so long that they won't be fixed
in any immediately following release either, so they should not block
1.0 any longer.

So what do you think? Is it 1.0 time...? And if yes, do we want to make
it extra-safe and start a release candidate cycle to flesh out possible
bugs with the new functionality?

Thomas.

  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Release time - au stdio update

[CooSoft Support]

Thomas Keller wrote:

Am 27.05.2010 12:56, schrieb Stephen Leake:
  

Thomas Keller m...@thomaskeller.biz writes:



Am 27.05.2010 10:22, schrieb CooSoft Support:
  

   Sounds like a great idea to me, especially the 1.0 bit :-)).

   However one minor point about the impending release (what ever
version it may be) :-(...

   I was looking at the changes for the next release and noticed the au
update command. Great, but why does it's progress messages go out on
stderr, should that not go out on stdout in the normal output stream
(possibly in stanza format)? 


First, a little background, just so we are all on the same page.
[...]


Yes, this is indeed a bug. Stephe, could you please have a look at
this?
  

I don't think this is a bug; I think it's a good example of 'au stdio'
streams, and an unfortunate side effect of the progress stream when not
using stdio.



Thanks for the explanation :) I haven't looked into the exact issue from
Tony - I thought though that he meant there is out-of-band stderr output
when using update over stdio. But if its all about progress messages he
complains about, then these should be properly streamed to the 'p'
(progress) stream already. If not, then that is a bug :)
  
Ok sorry for the confusion. I don't have access to my dev box at the 
moment. When Thomas suggested a new release I looked at the release 
notes and documentation regarding au stdio changes and read up on the 
new update command. Virtually all other au commands if not all simply 
mention what comes out on stdout by implication (apart from the barfing 
to stderr and exiting on error bit), update specifically mentioned 
stderr with reference to progress output, hence my, unfounded, concern. 
Monotone::AutomateStdio is totally based on au stdio so having it pop 
out on the p stream is what would be expected.


I got the wrong end of the stick from the documentation - sorry for the 
time wasted... :-(


Tony.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: [ANN] monotone 0.44 released

[CooSoft Support]

There may also be issues (probably not with mtn though) with the libc 
runtime as it uses dynamic loading of certain plugin libraries for 
authentication and hostname resolution (have seen this with some systems).


The -Wl,Bstatic -Wl,Bdynamic switches are useful around the libraries 
that you want to statically link.


Tony.

Zack Weinberg wrote:

On Sun, May 31, 2009 at 5:57 AM, Stephen Leake
stephen_le...@stephe-leake.org 
  

How do you accomplish this? The monotone Makefile builds a dynamically
linked executable.


Simply by building the libraries with --disable-shared, and (in case
of libidn which doesn't care about user wishes) moving the dll (and
.dll.a) aside. The build automatically picks up the static
libraries.
  

configure doesn't take option --disable-shared. Or at least, it
accepts that option, but it has no effect (I only tested this on
Debian; my Windows system needs to be rebuilt).



I think he means building all the *libraries* with --disable-shared,
so that there aren't shared libraries for the system to pick up.

  

So it would be useful if configure (or the Makefile) supported a
--disable-shared option.



This is a little harder than it looks because nowadays pkg-config goes
to some length to not list recursive dependencies in its --libs output
(these are harmful for shared linkage, but required for static
linkage, for stupid historical reasons both ways).  It could be done
but it would require modifying the autoconf scriptage around
pkg-config as well as the ultimate link line.

Also, there's a very real question of exactly how static you want your
binary to be.  If I were doing it I would probably preserve shared
linkage against everything that the compiler implicitly includes
(libstdc++, libgcc_s, libc, and possibly one or two others) because
staticly linking those can cause bizarre problems, but if you have
libstdc++ version skew to deal with that may not be good for you
either...

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

  




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] mtn log now converts dates to the user's timezone

[CooSoft Support]

   I was only referring to localtime vs UTC and not its format. I 
should have made that clearer :-).


   I do use the au stdio if extensively for mtn-browse. Whilst I agree 
the -mm-ddThh:mm:ss format should be constant regardless within au 
stdio I would have thought it best that the time was localtime as we 
will get out of say mtn log. This will avoid accidental/confusing 
inconsistencies.


   System UTC time_t vs formatted string... Another thing to consider. 
If one is using C/C++/Perl/Python etc then it doesn't make that much 
difference, as there are routines to convert formatted time back to 
time_t or struct tm etc. But if you are trying to hack something up in 
say Bourne shell then it would matter a lot. At least something 
resembling a human understandable local time can be used as is without 
costly or near impossible conversions in shell script.


   btw au is still a presentation layer, its just presents its data in 
a more parse-able format.


   Tony.
Zack Weinberg wrote:

At present, the only thing affected is 'log'.  My immediate thought is
that absolutely we should *not* apply these changes to the automate
interface, because that's intended for machine consumption; in
particular, you don't want to have to parse whatever arbitrary gunk
the user put in their date format spec.

On the other hand I've never written anything that consumed automate
output.  Are there contexts where it would be useful to get dates
(specifically, the values of date certs) still in ISO date format but
converted to the local time zone?

zw

On Fri, May 29, 2009 at 12:15 PM, Support supp...@coosoft.plus.com wrote:
  

Presumably these display times in local time changes will also affect
any dates/times output via au and au stdio?

Many thanks for making these changes btw :-)...

Tony.



This has been requested many times - I just now got around to doing
it.  You get output like this:

o   -
|   Revision: a12108115b1ba91ab5bc3cb58700f35c93fa18b0
|   Ancestor: 31dc9889d2a9a1fecc4acf1abb8703aec3ea9113
|   Author: mtn-...@zackw.users.panix.com
|   Date: 27 May 2009, 01:23:19 PM
|   Branch: net.venge.monotone

There's command line options and a Lua hook to turn it off and/or
customize the date formatting.

I think log is the only command that actually prints dates to the
user -- it would be easy to change any other command that does the
same.

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

  





  




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Can we

[CooSoft Support]

   Hi Dhana,

   The short answer is probably not and it has not been tested...

   The long answer is:

   Whilst Perl is platform independent, and Monotone::AutomateStdio 
strives to be, the GUI libraries that mtn-browse depend on are not 
necessarily so flexible. Gtk works natively under MS-Windows, but Gnome 
may well be a problem (it does all the desktop integration things like 
help and call up an applications based on file types etc...).


   There is a Linux environment for Windows called Cygwin under which 
mtn-browse may well run without a hitch. But it is untested.


   Once I have the Linux/Unix and Mac issues sorted. The next thing on 
my list is to see what is required to get this working on MS-Windows 
natively.


   Also I am the only developer on mtn-browse and so I am quite happy 
to be emailed directly regarding this app.


   Regards,

   Tony.
Dhana Sekar wrote:

Hi everyone,
 
Can we use mtn-browse on Windows?

Thanks.
 
regards

Dhanasekaran



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
  




___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel