Hello everyone!
I thought to contribute this smallish interactive script, which I use to
manually commit signed tags after "mtn git_export".
Note: if run as "tag-script auto" it will non-interactively recommit all
of the existing lightweight tags w/o changing names. Also, best use
with gpg-agent
On Fri, 23 May 2008 13:39:18 +1000
William Uther <[EMAIL PROTECTED]> wrote:
> I've just added a simple warning in rev
> e70f33adec836ae22060c9d5be519d387e7852f0
>
> Here is a transcript showing the warning:
>
> % mkdir dir
> % touch dir/fileA
> % touch dirB
> % mtn add --unknown
> mtn: adding
On Thu, 22 May 2008 07:17:05 -0500
Matthew Nicholson <[EMAIL PROTECTED]> wrote:
> > Yury Polyanskiy wrote:
> >> Please consider this bug... It always causes problems when updating
> >> upstream releases: you update, make a tag then realize that
> >> someth
Dear monotone-devel,
There is a 100% reproducible bug (that was reported 6 months ago by
someone under http://savannah.nongnu.org/bugs/index.php?21545)
However, I find the discription there a little misleading. What happens
is the following:
$ mtn co -b test test
$ cd test
$ mkdir aaa; echo "hel
On Thu, 2006-05-18 at 00:27 -0700, Nathaniel Smith wrote:
> You need to add "-p0" to this last command.
>
Oh, thanks! My fault.
But even with it:
==
$ mtn diff -r 3895c20299d04 Makefile >~/tmp/p1
$ cd ..
$ mtn --db=/path/my.db co -r 3895c20299d04 Lm2/
$ cd Lm2/
$ patch -p0 <~/tmp/p1
On Wed, 2006-05-17 at 22:26 -0700, Justin Patrin wrote:
> Sure it canof course renames don't work as normal diff doesn't
> deal with renames.
>
$ mtn diff -r 3895c20299d04 >~/tmp/p
$ cd ..
$ mtn --db=/path/my.db co -r 3895c20299d04 Lm2/
$ cd Lm2/
$ patch <~/tmp/p
patching file ChangeLog
patch
On Mon, 2006-05-15 at 09:16 -0700, Nathaniel Smith wrote:
> Perhaps to inspire someone :-):
The most exciting that I found in those pictures:
* merge _THEN_ commit separately -- this is simply wonderful.
* hg export: it's a little annoying that monotone's diff is not
standard one (i.e. can not
On Mon, 2006-02-27 at 13:09 +1100, Matthew Hannigan wrote:
>
> I thought the most name obvious would be 'mon'
>
I use mon too.
YP.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-dev
On Mon, 2006-02-27 at 01:21 -0800, Nathaniel Smith wrote:
> Do you feel like this email is something you can point people at if
> they complain that monotone changes too often? Do you feel like this
> amount of change is reasonable?
Well, thank you Nathaniel for a complete and very reasonable
ex
On Sun, 2006-02-26 at 04:15 -0800, Nathaniel Smith wrote:
> -- Having a single, standard abbrev is very useful. If, for
> instance, we switch the command name to "mtn", we should also (I
> suggest):
>-- make the bookkeeping directory MTN (instead of MT)
>-- make the ign
Hi all!
I just found an interesting case when monotone log order is somewhat
puzzling.
Ok. Here is my graph. First I created initial revision A and worked on
the project for a month or so:
A->B->...->R
Now I wanted to import a patch made against original A. So I commited
that patch and merged a
On Fri, 2006-02-17 at 01:54 -0600, [EMAIL PROTECTED] wrote:
> Hi. A error message told me to post a copy of itself here.
>
> The summary is that "monotone --db=~/libs/monotone-archive.db serve
> 10.9\9.99.3
> 1:5253 com.dlsemc.intranet" chokes and won't start up in 0.25
The problem is that your
On Thu, 2006-02-02 at 21:48 -0600, Glen Ditchfield wrote:
> For operation 2, this is good. For operation 1, would it be good to split in
> a platform-agnostic manner, provided that the file is internally consistent?
> - If the file contains LFs but no CRs, split on LFs.
> - If the file contains C
On Thu, 2006-02-02 at 11:45 -0800, Graydon Hoare wrote:
> Is this a clear enough position for everyone?
Dear Graydon,
My original question was very simple: how you specify what "treat by a
sequence of lines" means? Does it mean converting all weird combinations
of CR and LF into line-ending or
On Thu, 2006-02-02 at 07:42 +0100, Richard Levitte - VMS Whacker wrote:
> I must say that I feel nervous handing the decision to a lua hook.
> There's the strong possibility that a user somewhere will get
> "creative" and that chaos will follow. If there's an attribute saying
> that a file shouldn
Well I think per-file certificate is something that doesn't fit in
monotone's model (certificates are attached to revisions not files).
In fact I think current implementation with get_linesep_conv() includes
every other model IF only I could check for "merge_manual" attribute
from inside the hook.
On Mon, 2006-01-30 at 13:59 +, Bruce Stephens wrote:
> I can believe that's true of some text files. But for (to take a
> random example) C++ source files, it's surely not true, is it?
That's the problem with current approach: it only takes C/C++ sources
into account.
> I'd expect to get C
On Mon, 2006-01-30 at 07:36 -0500, Ethan Blanton wrote:
> This is precisely why Yury is correct. Because, on many systems, \r
> and \n have _different meanings_, they should be properly and
> reversibly preserved even in text files. What Yury is saying, if I
> understand it correctly, is that the
Hi all!
I just finished testing the tool for exporting BitKeeper repositories to
monotone. It is based on SourcePuller-0.2 by Andrew Tridgell.
Core features:
* no need to have BitKeeper copy installed -- you need only your
repository (local copy or available for clone)
* non-linearized version is
On Sun, 2006-01-29 at 21:32 +0100, Richard Levitte - VMS Whacker wrote:
> Nope. Consider a binary file, which might contain anything and let's
> consider a get_linesep_conv that always returns {"LF","CR"} (because
> we run it on Mac, that's why). Let's use a hypothetical monotone that
Well I wa
On Sun, 2006-01-29 at 20:54 +0100, Richard Levitte - VMS Whacker wrote:
> The two line endings returned by get_linesep_conv() are only used when
> writing the files. When reading them (at least when reading them from
> the workspace), monotone is trying to be smart and looks for all kinds
> of lin
On Sun, 2006-01-29 at 19:42 +0100, Jon Bright wrote:
> Me too. I've always argued that the database should have the canonical
> form (and that this canonical form should be LF-only for text files and
> whatever-the-file-has for binary or other "don't mess with the line
> endings" files). My re
Richard and Bruce,
I'm sorry for confusion. I said from the very beginning that it is my
fault to use conversion for binary files.
What I say is that if someone sets conversion (whatever he wants
charset, lineending) he can expect that *ANY* data will be converted
back to the same state before d
Good day again!
Sorry, for asking. I know it's all in sources but just in case someone
has a spare second: Is it possible to check if attribute "manual_merge"
is set on a file from hook get_linesep_conv()?
Note: it's not a solution to read and parse .mt-attrs because
get_linesep_conv() may be ca
Hi all!
I think there is a bug in CRLF<->LF conversions or at least unintended
behavior.
Suppose the following scenario.
function get_linesep_conv(fname)
return {"LF", "CRLF"}
end
I expect to have all files translated from LF to CRLF after checkout
with this hook. Indeed that ha
but propagate from devel to mainline still suffers from lack of
merge-via-working-dir as you say.
It was really a shock to me when after so much excitement about the
design of monotone I found that once I had a merge conflict I CAN NOT
hit exit and fix everything in the tree myself (ensuring that
from BK to monotone (the idea of tailor is
different: passing csets here and there).
On Sun, 2006-01-15 at 21:27 -0800, Nathaniel Smith wrote:
> On Sun, Jan 15, 2006 at 10:31:13PM -0500, Yury Polyanskiy wrote:
> > This won't handle all situations: suppose a merge revision that adds a
This won't handle all situations: suppose a merge revision that adds a
file. I can't direct monotone to add a new file via merge hook.
Yury.
On Mon, 2006-01-16 at 14:19 +1100, Daniel Carosone wrote:
> Yes, you'll need to set manual_merge to true. A switch to merge to
> imply this for all files i
Oh, ok. I knew I was missing something obvious. Sorry for not RTFMing
enough.
I'm not talking about a quick hack but rather a complete lossless
converter from BK to monotone. The way to do this is to either integrate
infamous SourcePuller (by A.Tridgell) inside monotone. However that
would probabl
Thanks all for replies!
I was 99% sure that the solution would be to commit my merged tree as a
child to revA and then call some fancy "monotone db execute 'insert...'"
to draw an additional edge in revision graph from revB to a newly
created revC.
Does anyone has a short explanation why such ``
Hey guys!
I'm rephrasing my last question.
I have a tree at some state. If I want to commit it as a child to ONE
revision I simply do echo $REVISION >MT/revision; monotone commit.
Now HOW to commit a tree as a child to TWO revisions? I.e. I want
current revision to be a child of revA and revB (
Hi all!
I have a naive question. I'm planning to import my projects from another
version control system for which I couldn't find any free tool (guess
which VCS I used ;-).
If the tree was linear then of course there're no problems. But if I
have branches I need to be able
1) to commit childre
32 matches
Mail list logo
