Steven == Steven E Harris [EMAIL PROTECTED] writes:
Steven Related question: In light of this rule, is there any way
Steven to revive a file in a later revision, if one realizes
Steven that a given branch should include the deleted file again?
I asked this question not long ago, it
On Tue, 28 Nov 2006, Patrick wrote:
One use case that may have been covered, but that I haven't seen addressed
yet:
I work (unfortunately) on a windows machine, but use cygwin where possible to
have a more familiar (sane) set of tools. On this machine, all of the source
code
has windows
On Sat, 2006-12-02 at 01:49 +, Boris wrote:
Hugo Cornelis wrote:
Well, what I really want to do is have a mechanism that automatically
distributes the necessary hooks from one central point. For sure the
members of the same team need the same trust policies, local
alterations not
On 12/2/06, Oren Ben-Kiki [EMAIL PROTECTED] wrote:
On Sat, 2006-12-02 at 01:49 +, Boris wrote:
Hugo Cornelis wrote:
Well, what I really want to do is have a mechanism that automatically
distributes the necessary hooks from one central point. For sure the
members of the same team need
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
- Tracking new versions of software:
$ tar -xvzf kphotoalbum-2006-11-27-noi18n.tar.gz
$ mtn import kphotoalbum-2006-11-27-noi18n \
-d {database} \
-b free.lp.se:kphotoalbum.import \
Oren Ben-Kiki wrote:
[...]
I guess it does not belong to monotone. As you even want to forbid
developers to change trust policies I think a distributed revision
control system is not what you want. What monotone does is copying
data between databases. Once it is there revisions can be
Oren == Oren Ben-Kiki [EMAIL PROTECTED] writes:
Oren Sounds strange to me. I'd expect the trust policy and (all?
Oren some?) of the hooks to be part of the data that monotone
Oren allows copying between the databases.
You have to be very careful about putting hooks directly into
Hi!
In the future several monotone commands not yet available via automate
will be available there (soon annotate, not that soon push/pull/sync).
Since these actions can take a little longer and may even reside on
network latency / throughput, there is no feedback to the calling
process if
Thomas Keller schrieb:
1:0:l:1:r
2:0:l:1:r
3:0:l:1:c
...
Answering my own post, Thomas Moschny proposed on IRC to add a new
output chunk type similar to m for more and l for last. This
could be named t for ticker and could include the resting number in
the payload for the current action.
Hi,
Just to provide more info, a subsequent run of the same command ended in
kachung:~/Development/OpenEmbedded/stuff# mtn
--db=/root/Development/OpenEmbedded/stuff/OE.mtn pull monotone.openembedded.org
org.openembedded.dev
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
Hi,
I am really new to Monotone.
I installed it on my Debian sarge, customized kernel to try out
OpenEmbedded (http://www.openembedded.org).
I was following the instructions given in
http://www.openembedded.org/wiki/GettingStarted and got to the
point of getting the monotone database,
Zbynek Winkler wrote:
In hg most of the commands operate on the whole tree by default (diff,
status, commit...) and output paths relative to the workspace root.
However when supplied with a path, status outputs paths relative to
the supplied path. If monotone did the same then there would be at
If it does not always fail the same way every time, you should check
for hardware faults (bad RAM, especially); monotone should be wholly
deterministic.
Note the double Segmentation fault... not sure if the last one is
printed by bash, or mtn runs two threads...
mtn's segfault handler prints
13 matches
Mail list logo
