[Monotone-devel] Directory already exists?

[J Decker]

Just a question... has anything been fixed in regard to directories existing?

It's yet again time to update some other boxes to current versions of
software I have dropped several directories

I started an update.. and got a new project directory added (box2d)..
but then it collided with some other project for which it issues
'warning: cannot create direcotyr, already exists' *BOMB*

okay fine... delete that directory... try an update

*several hundred files report as missing*
... sigh ...
mtn revert --missing
mtn update

*warning cannot create path box2d, already exists* well of course it
does, I just got through a partial update!

okay remove box2d
mtn update
*forget about the missing files again*
mtn revert --missing

err what was that original directory it had a problem with?

mtn ls unknown
*thousands and thousands of files cause of course I have built this
project with 5 compiles with 3 different compilation modes*

so the real question.


if a file doesn't exist, and it's going to be deleted anyway... why complain?
if a directory already exists, so what?  presume it was already added
by a incomplete update and continue

*blow away workspace*
checkout again (the main project plus the 3 sub projects)

And then I ask myself ... why is it I liked monotone?


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

Re: [Monotone-devel] Directory already exists?

[J Decker]

This is 0.36 (37?) every version since well forever under windows...



On Dec 15, 2007 3:20 PM, Brian May <[EMAIL PROTECTED]> wrote:
> >>>>> "J" == J Decker <[EMAIL PROTECTED]> writes:
>
>J> *warning cannot create path box2d, already exists* well of
>J> course it does, I just got through a partial update!
>
> By "partial update" I assume you mean monotone half completed the
> update and left the working directory in a inconsistent state as a
> result.

Yes, exactly.

>
> Updates should be atomic. Either it fully works or doesn't work at
> all.

Really? think that's what I've been complaining about for months

>
> If the update isn't atomic, maybe that is the bug you need to chase.
>

psh why? I keep getting told that this is not an unexepected behavior,
and that I should think it should work is my problem.

> What version of monotone is this?
> --
> Brian May <[EMAIL PROTECTED]>
>
>
> ___
> 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

Fwd: [Monotone-devel] Directory already exists?

[J Decker]

-- Forwarded message --
From: J Decker <[EMAIL PROTECTED]>
Date: Dec 18, 2007 5:11 PM
Subject: Re: [Monotone-devel] Directory already exists?
To: Timothy Brownawell <[EMAIL PROTECTED]>


Having thought about this a bit more... if a directory is an object,
why can't it just be merged with other changes?  If I make a
modification to a file, and create a line, when an update happens,
changes are merged even with the new lines... I mean lines are objects
at a certain point.

I guess though if there is a conflict in that created line that
already exists during an update... err no wait

if I make a modification to a file, add a line, commit it.

go to another box, and make the same creation to another file, the
update basically just updates the revision number, and no change is
done to the file... the file is not reported as 'updated' during the
status of the update command.






On Dec 16, 2007 3:01 PM, Timothy Brownawell <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-12-13 at 15:54 -0800, J Decker wrote:
> > Just a question... has anything been fixed in regard to directories 
> > existing?
> >
> > It's yet again time to update some other boxes to current versions of
> > software I have dropped several directories
> >
> > I started an update.. and got a new project directory added (box2d)..
> > but then it collided with some other project for which it issues
> > 'warning: cannot create direcotyr, already exists' *BOMB*
> >
> > okay fine... delete that directory... try an update
> [...]
>
> Yeah... what we *should* do is check for blocked adds or renames (or
> missing files) before doing anything, so we don't leave stuff all mixed
> up in pre-detectable cases (locked files or races with other programs
> would still cause issues).
>
> This would actually be fairly similar to the code needed to, say, make
> updates undoable/restartable (generate a complete list of adds / drops /
> renames to do, in order, and work from that). Not sure how involved that
> would be, I haven't looked at that part of the code in a while...
>
> (Hmm, do we know of a good cross-platform library to provide
> atomic/durable filesystem transactions?)
>
> > if a file doesn't exist, and it's going to be deleted anyway... why 
> > complain?
>
> Because our error handling tends to be "when in doubt, abort".
>
> > if a directory already exists, so what?  presume it was already added
> > by a incomplete update and continue
>
> We currently think of directories as objects, so stomping on an existing
> directory is just as bad as stomping on an existing file.
>
>
> --
> Timothy
>
> Free (experimental) public monotone hosting: http://mtn-host.prjek.net
>
>


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

Fwd: [Monotone-devel] Directory already exists?

[J Decker]

-- Forwarded message --
From: J Decker <[EMAIL PROTECTED]>
Date: Dec 18, 2007 4:59 PM
Subject: Re: [Monotone-devel] Directory already exists?
To: William Uther <[EMAIL PROTECTED]>


Just so y'all know... (this reply is basically out of sequence)

the best way to update when this condition exists...
get the head revision, update _MTN/revision and mtn revert

revert has 0 problems updating *boggle*


On Dec 18, 2007 10:50 AM, William Uther

<[EMAIL PROTECTED]> wrote:
>
> On 18/12/2007, at 12:58 AM, Nathaniel Smith wrote:
>
> >
> > On Mon, Dec 17, 2007 at 06:15:11PM +1100, Brian May wrote:
> >>>>>>> "Timothy" == Timothy Brownawell <[EMAIL PROTECTED]> writes:
> >>
> >>>> if a directory already exists, so what?  presume it was already
> >>>> added by a incomplete update and continue
> >>
> >>Timothy> We currently think of directories as objects, so stomping
> >>Timothy> on an existing directory is just as bad as stomping on an
> >>Timothy> existing file.
> >>
> >> I consider this a good thing. If I manually created a directory and
> >> it
> >> conflicts with an update, chances are I didn't realize that the
> >> directory name was already in use. I don't want monotone to assume
> >> that the purpose of the new directory is compatible with the
> >> directory
> >> in the repository, as this may not be the case.
> >
> > Well, trashing the workspace is never a good thing, no matter how
> > noble the intentions :-).
> >
> > Could we just handle this case by issuing a warning and continuing
> > anyway?  Seriously, it would be like 3 lines of code and definitively
> > better than what we have now...
>
> Just a thought on the atomic workspace thing...
>
> If monotone took a diff before attempting an update, then if something
> went wrong you could always reconstruct the state before the update.
>
> In fact, isn't there a system out there that requires all changes be
> committed before an update, at least onto an anonymous branch?
>
> Cheers,
>
> Will   :-}
>
>
>
>
> ___
> 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

[Monotone-devel] Monotone update failures...

[J Decker]

Create a branch... check it out

add a directory
add a 2 file in the directory

mtn add one of the files
mtn commit --branch=new.branch
mtn update -r h:branch

mtn.EXE: target revision is not in current branch
mtn.EXE: switching to branch branch
mtn.EXE: warning: cannot drop non-empty directory 'include/internal'

mtn.EXE: misuse: 1 workspace conflicts

was going to further do...

mtn add the_other_file

(I creted both files, but one was not ready for the main branch, so I
commited that on a second branch, the other I wanted to put back in
the first branch...)

probably would end up with some sort of non-content conflict like
adding include/internal directory 2x ... killing possiblity of
propagation


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

[Monotone-devel] how do I list what the last changes were?

[J Decker]

How do I get the list of branches ordered by most recent commit?  I
got 4 revisions, but I dunno which branch they apply to.


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

[Monotone-devel] Boost AGAIN?

[J Decker]

I thought y'all just remove dependance on the boost beast...

it's back, and for some silly reasons?  zlib?

salright I happened to have it in uninstalled and could resurrect it.

J


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

[Monotone-devel] Database locked...

[J Decker]

Monotone previously did not do this... but I have a server that serves
a .DB file.  On the same server I'm using viewmtn to check statuses of
branches,etc.  Our server recently crashed, so I ended up installing
the latest monotone.

At some point during 0.3x monotone's behavior changed from being able
to use the same database after a sync completed to  being locked after
a sync.

Now, as soon as the server starts, the database is locked, and no
other mtn may access it.

I checked real quick for running mtn through xinetd... but I guess
that's not probable?

How can I use viewmtn on the host with my central repository?


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

[Monotone-devel] Monotone windows release 0.44....

[J Decker]

Why are zlib1.dll, libpcrecpp-0.dll and libpcreposix-0.dll  included
in the installation if they aren't used?

copying mtn and dependancies only copes [ libiconv-2.dll libidn-11.dll
libintl-8.dll libpcre-0.dll mtn.exe  ]

I guess they might be dynamically loaded with LoadLibrary and
GetProcAddress... but there's no reference of the text 'zlib' in any
of the files except zlib1.dll...  uhmm I guess it might be unicode...


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

Re: [Monotone-devel] Monotone windows release 0.44....

[J Decker]

Hrm... that doesn't help me that's a list from a Linux or other
distribution, the subject is Windows 0.44.

On Thu, May 21, 2009 at 4:18 PM, Zack Weinberg  wrote:
> zlib most definitely is used, but it might not be that copy of it
> that's getting used.  libpcrecpp-0.dll and libpcreposix-0.dll, on the
> other hand, are definitely *not* needed.  We don't play tricks with
> LoadLibrary as far as I know.
>
> For reference, this is the set of libraries required in an
> as-dynamically-linked-as-possible Linux build:
>
> $ objdump --private-headers /usr/bin/mtn | grep NEEDED
>  NEEDED               libpcre.so.3
>  NEEDED               libbotan-1.8.2.so
>  NEEDED               liblua5.1.so.0
>  NEEDED               libsqlite3.so.0
>  NEEDED               libidn.so.11
>  NEEDED               libz.so.1
>  NEEDED               libstdc++.so.6
>  NEEDED               libm.so.6
>  NEEDED               libgcc_s.so.1
>  NEEDED               libc.so.6
>
>
> On Thu, May 21, 2009 at 4:11 PM, J Decker  wrote:
>> Why are zlib1.dll, libpcrecpp-0.dll and libpcreposix-0.dll  included
>> in the installation if they aren't used?
>>
>> copying mtn and dependancies only copes [ libiconv-2.dll libidn-11.dll
>> libintl-8.dll libpcre-0.dll mtn.exe  ]
>>
>> I guess they might be dynamically loaded with LoadLibrary and
>> GetProcAddress... but there's no reference of the text 'zlib' in any
>> of the files except zlib1.dll...  uhmm I guess it might be unicode...
>>
>>
>> ___
>> 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] Monotone windows release 0.44....

[J Decker]

yes - but a simple visual inspecition like objdump does searching for
.dll in the binary reveals no reference of the .dll...

pedump lists







Imports Table size:7680

 offset 8817152 libidn-11.dll
 offset 8817172 libintl-8.dll
 offset 8817192 libpcre-0.dll

 offset 8817212 KERNEL32.dll

 offset 8817252 msvcrt.dll
 offset 8817272 SHFOLDER.DLL
 offset 8817292 USER32.dll
 offset 8817312 WS2_32.DLL



lilbintl-8 and libidn-11 reference libiconv-2.dll  (as seen by pedump)

- Show quoted text -


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

Re: [Monotone-devel] Monotone windows release 0.44....

[J Decker]

depends indicates that the files I copied using my program which is
also able to find the refernced DLL's (and their refrenced dlls) has
no missing dependancies, and is only the 5 files I listed to start.

depends on the initial installation reveals no reference to zlib1.dll


On Thu, May 21, 2009 at 4:34 PM, Thomas Keller  wrote:
> J Decker schrieb:
>> On Thu, May 21, 2009 at 4:18 PM, Zack Weinberg  wrote:
>>> zlib most definitely is used, but it might not be that copy of it
>>> that's getting used.  libpcrecpp-0.dll and libpcreposix-0.dll, on the
>>> other hand, are definitely *not* needed.  We don't play tricks with
>>> LoadLibrary as far as I know.
>>>
>>> For reference, this is the set of libraries required in an
>>> as-dynamically-linked-as-possible Linux build:
>>>
>>> $ objdump --private-headers /usr/bin/mtn | grep NEEDED
>>>  NEEDED               libpcre.so.3
>> Hrm... that doesn't help me that's a list from a Linux or other
>> distribution, the subject is Windows 0.44.
>>
>
> What does Depends.exe [0] show you?
>
> [0] http://www.dependencywalker.com/
>
> --
> GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
> Please note that according to the EU law on data retention, information
> on every electronic information exchange might be retained for a period
> of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
>
>


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

[Monotone-devel] Monotone serve - no listen port opened?

[J Decker]

How can I validate (other than with netstat) that monotone is opening
a tcp port?  (I tried adding the --bind 0.0.0.0:4691 and --bind :4691
and --bind :4691, and none of them opened a port, as seen
in 'netstat -ant' (linux)

If I configure monotone as an xinetd service, I would basically just
'mtn serve --stdio'  ?  (this doesn't sync either)


My windows version indicates it's opening an interface to serve on, I
get no statuses from my linux version

also tried --debug option to observe in the log, but there's no
mention of sockets or tcp there...


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

Re: [Monotone-devel] Monotone serve - no listen port opened?

[J Decker]

uhmm... how do I track what code is to blame for this ?


read(5, 
"\3276\211\241\353o\336\362\255\327\333\360\314\341\372\376\t1\5\364V\374\35U7\340\316$)\221\231\263R"...,
96) = 96
open("/proc", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
fstat(6, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
getdents(6, /* 33 entries */, 1024) = 1016
lstat("/proc/mdstat", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/mdstat", O_RDONLY|O_NOCTTY) = 7
read(7, "Personalities : \nunused devices: "..., 4096) = 40
close(7)= 0
lstat("/proc/asound", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/asound", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/partitions", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/partitions", O_RDONLY|O_NOCTTY) = 8
read(8, "major minor  #blocks  name\n\n   8 "..., 4096) = 177
close(8)= 0
lstat("/proc/diskstats", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/diskstats", O_RDONLY|O_NOCTTY) = 8
read(8, "   8   0 sda 247148 22306 106"..., 4096) = 396
close(8)= 0
lstat("/proc/crypto", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/crypto", O_RDONLY|O_NOCTTY) = 8
read(8, "name : stdrng\ndriver "..., 4096) = 359
close(8)= 0
lstat("/proc/key-users", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/key-users", O_RDONLY|O_NOCTTY) = 8
read(8, "0: 3 2/2 0/200 0/2\n"..., 4096) = 31
close(8)= 0
lstat("/proc/keys", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
open("/proc/keys", O_RDONLY|O_NOCTTY)   = 8
read(8, ""..., 4096)= 0
close(8)= 0
lstat("/proc/kpageflags", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
open("/proc/kpageflags", O_RDONLY|O_NOCTTY) = 8
read(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
close(8)= 0
lstat("/proc/kpagecount", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
open("/proc/kpagecount", O_RDONLY|O_NOCTTY) = 8
read(8, "\1\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\1"...,
4096) = 4096
close(8)    = 0
lstat("/proc/kmsg", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
open("/proc/kmsg", O_RDONLY|O_NOCTTY)   = 8
read(8,  
mtn: operation canceled: Interrupt


(proc/kmsg blocks )

On Tue, Jun 2, 2009 at 3:54 PM, Zack Weinberg  wrote:
> On Tue, Jun 2, 2009 at 3:24 PM, J Decker  wrote:
>> How can I validate (other than with netstat) that monotone is opening
>> a tcp port?  (I tried adding the --bind 0.0.0.0:4691 and --bind :4691
>> and --bind :4691, and none of them opened a port, as seen
>> in 'netstat -ant' (linux)
>
> Try strace; the last few operations should be something like this
> (beware, the trace may include your pass phrase in cleartext):
>
> $ strace mtn -d monotone.mtn serve
> ...
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 13
> fcntl(13, F_GETFL)                      = 0x2 (flags O_RDWR)
> setsockopt(13, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(13, {sa_family=AF_INET, sin_port=htons(4691),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 14
> fcntl(14, F_GETFL)                      = 0x2 (flags O_RDWR)
> setsockopt(14, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> setsockopt(14, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
> bind(14, {sa_family=AF_INET6, sin6_port=htons(4691),
> inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0,
> sin6_scope_id=0}, 28) = 0
> listen(13, 128)                         = 0
> listen(14, 128)                         = 0
> write(2, "mtn: beginning service on  mtn: beginning service on  : 4691
> select(15, [13 14], [13 14], [13 14], NULL
>
> and then it should block until a connection is received.
>
> zw
>


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

Re: [Monotone-devel] Monotone serve - no listen port opened?

[J Decker]

(I did find a work around: if I run it as a user account, it kindly
fails[eaccess], and proceeds  )


monotone 0.44 (base revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
Running on  : Linux 2.6.29.2 #1 SMP Tue May 12 18:14:24 PDT 2009 x86_64
C++ compiler: GNU C++ version 4.3.3
C++ standard library: GNU libstdc++ version 20090124
Boost version   : 1_38
SQLite version  : 3.6.14.1 (compiled against 3.6.14.1)
Lua version : Lua 5.1
PCRE version: 7.9 2009-04-11 (compiled against 7.9)
Botan version   : 1.8.1 (compiled against 1.8.1)
Changes since base revision:
format_version "1"

new_manifest [e4fc965aec46ce8b371e818de6092168e1b6f52f]

old_revision [7a4832143b3146ca89f5cb91e0e571d05e29d4b9]

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






On Tue, Jun 2, 2009 at 5:32 PM, Jack Lloyd  wrote:
> On Tue, Jun 02, 2009 at 05:30:43PM -0700, J Decker wrote:
>> uhmm... how do I track what code is to blame for this ?
> [...]
>> (proc/kmsg blocks )
>
> *blush*
>
> This looks a lot like it is botan polling /proc to get entropy to seed
> the PRNG.
>
> Can you post `mtn version --full`?
>
> -Jack
>
>
> ___
> 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

[Monotone-devel] ViewMTN mirror?

[J Decker]

http://grahame.angrygoats.net/viewmtn.shtml  seems to be down?

Is there a latest copy of viewmtn I can use with 0.44 ?


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

[Monotone-devel] GUIs, Frontends, and is anyone 'famous' using this?

[J Decker]

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

There is some incompleteness in the forementioned link... like whether
monotone does cherrypicking etc...


Recently, it seems that mercurial has gotten Tortoise plugin support,
so now i have svn and possibly mercurial available from internet
explorer.  But, is there anyone out there working on Visual Studio
plugin?  I see that there's an eclipse plugin, with perhaps support.
(Does it work well??)

re: ViewMTN - is there a new maintainer, with a new host? is it all
modernized and compatible with latest python/apache/monotone?

The players at the table for our discussion - git (sorta), mercurial
(now with user-sloth-inducing-enhancements, I mean user-friendlyness
like tortoise), bazaar, each of these has a big player or two
associcated with their usage (linux kernel, MySQL is using bazaar (or
was), I forgot the magjor players using mercurial now 3 or 4 of em I
think), and I'm trying to keep monotone on the table, because it has
technical features superior to all of the others (except perhaps git,
which fails due to complexit, but anyhow)

Primarily with mercurial and bazaar, each workspace is a repository...
so I have no cross-workspace sharing (other than mounting them both
within each other perhaps, and manually commiting between them).  They
also would never support something like merge_into_dir.  But - this
makes usage simpler (?)... I mean you never have to specify --db= ...
which after you've got your workspace setup, you never need to worry
about.  Also, their access control seems to rely on operating system
features (ssh permission, http access), rather than specify which
users can use(commit to) which branches

Is there any other slick GUIs anyone's been working on?


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

[Monotone-devel] Version Control System Review

[J Decker]

I found this an interesting read.  It's a fairly unbiased (maybe)
review of most modern version control systems, and even some
benchmarks in the part 3...

http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-1
http://ldn.linuxfoundation.org/article/dvcs-roundup-one-system-rule-them-all-part-2
http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3


I'm sad to see monotone do so badly no the benchmark page, it's still
wickedly awesome.


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

[Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...

[J Decker]

When I abort an operation in monotone for windows, an exception is
generated.  I have tolerated this since version 0.26... but... no I'm
tried of having to wait for the exception handler to log the
exception... y'all should implement

SetConsoleCtrlHandler

and handle exiting nicely instead of blowing up.  PLEASE!

If I start a mtn log (that's too long) or mtn commit, and relaize I
messed up the message, or a sync, and realize there was another commit
I wanted... I often halt a montone op with ctrl-c


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

Re: [Monotone-devel] ViewMTN maintainer

[J Decker]

Nice, works pretty well.  I do miss the More/Less revisions on the
graph feature, however... Used to be able to show the past to see a
tangled mess of branches +/- 2 revisions from the current' isn't
always a good enough picture.

On Mon, Nov 2, 2009 at 3:00 AM, Thomas Moschny  wrote:
> Hi!
>
> Just to let you know, that the new home of ViewMTN is here:
> http://viewmtn.1erlei.de/ . There's also a live ViewMTN instance at
> http://mtn-view.1erlei.de/ carrying the nvm* branches as well as some
> random other branches that are mtn-related.
>
> Feel free to send me comments or hints regarding ViewMTN or the website,
> or if you like to see some other branches served there.
>
> Note that the new home of the project is in fact a Trac instance, so the
> preferred way of communicating is to open a ticket there.
>
> Btw, if someone here has graphic artist skills... a good idea for a logo
> is more than welcome ;)
>
> Regards,
> Thomas
>
>
> I wrote:
>> Hi Grahame,
>>
>> Grahame Bowland wrote:
>>> It's over a year since I did much on ViewMTN. I'm not interested in
>>> continuing to work on the project, so I'm looking for someone to take
>>> over maintainership. If anyone puts their hand up I am more than happy
>>> to help with any questions or problems. Thanks in advance to anyone
>>> that puts their hand up!
>>
>> First of all thanks for developing that useful front-end!
>>
>> If no one else want to take over maintainership, I could step in -
>> maintaining your package in Fedora anyway on the one hand, and having
>> some Python code interfacing Monotone on the other hand.
>>
>> Maybe we can discuss details off-list.
>>
>> - 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

[Monotone-devel] Rename is not Move

[J Decker]

I'm trying to rename a directory 'libpng-1.2.31' to 'libpng-1.2.40'
but when I do

mtn rename libpng-1.2.31 libpng-1.2.40

it tells me that destination libpng-1.2.40 is not a directory.


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

Re: [Monotone-devel] How to split a project

[J Decker]

The other method is to make a quick commit with --branch=program1
branch pivot_root  < program1's new root directory> old_root - will
put all files in the root into old_root and make the program
directories current.  You can then use mtn drop to drop old_root.

this is bad, in that you cannot propagate to this new changes to the
common trunk... but if you're really just making a new trunk, but want
to retain the revision history, as long as you do not ever propagate
between these, it's not so bad.

Oh I guess the more important direction is that you cannot propagate
from the pivoted branch to the main, as it would inherit the pivot.  I
really this the pivot point should be handled differently

maybe someone could make a new operation that is a sensible 'make this
point in a branch a seperate branch, which I can propagate to and from
the main trunk (only changes to files within that branch basically)'



On Mon, Feb 22, 2010 at 6:45 AM,   wrote:
> Let's say I have some code checked in along some branch.  Over the year
> it has evolved so that it has become two separate programs, that don't
> share any code any more, and make sense to develop independently.
>
> Evidently, it makes sense to make two branches, one for each program.
> The obvious way is just start new branch(es) and in each branch delete
> all the files now belonging to the other.
>
> BUT.  If years down the line, someone wants to include both these
> programs into another project, I don't want the merge saying, let's
> merge all these changes.  Looky here, all the files of each branch have
> been deleted on the other.  There's nothing left!  And that someone
> mysteriously end up with no files instaed of all the files.
>
> Is there a better way to split a project?  If not, should there be?
>
> Or,
>
> Am I worrying about nothing?
>
> -- 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] Okay I'm tired of exception when aborting windows mtn command...

[J Decker]

ExitProcess invokes things like static class destructors, and atexit()
registered code.  Terminate process ends the process immediately.
Probably the default break handler calls ExitProcess... and don't you
mean a break handler that returns TRUE so it doesn't segfault?

On Tue, Mar 2, 2010 at 12:43 PM, Timothy Brownawell  wrote:
> Way back in October, Timothy Brownawell wrote:
>>
>> J Decker wrote:
>>>
>>> When I abort an operation in monotone for windows, an exception is
>>> generated.  I have tolerated this since version 0.26... but... no I'm
>>> tried of having to wait for the exception handler to log the
>>> exception... y'all should implement
>>>
>>> SetConsoleCtrlHandler
>>>
>>> and handle exiting nicely instead of blowing up.  PLEASE!
>>
>> Patches welcome?
>>
>> I've tried this before, but IIRC calling ExitProcess() from the handler
>> would still segfault (I also think I recall trying TerminateProcess()
>> with the same result, but that doesn't seem to make sense).
>
> Without a ctrl handler (how things are now), ^C causes a segfault.
>
> With a ctrl handler that returns FALSE (makes it call the default handler),
> it segfaults.
>
> With a ctrl handler that calls ExitProcess(), it segfaults.
>
> With a ctrl handler that returns TRUE (don't call the next handler), it
> *exits*.
>
> With a ctrl handler that calls TerminateProcess(), it exits.
>
> If I run from cmd.exe instead of the msys shell...
>        returning FALSE segfaults
>        returning TRUE does nothing (like it should)
>
>
>
> So... maybe we should have a ctrl handler that returns FALSE after setting a
> flag to make the segfault handler print a less dire message? I'm not sure
> how to make sense of what it's doing.
>


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

Re: [Monotone-devel] Time for a release

[J Decker]

pedump can list what a program is linked to...

http://www.wheaty.net/



On Mon, Mar 8, 2010 at 6:11 AM, Timothy Brownawell  wrote:
> Stephen Leake wrote:
>>
>> The following tests are failing on Win32:
>>
>>  9 (normal)_netsync_on_partially_unrelated_revisions FAIL (error creating
>> test directory) 0:00, 0:00 on CPU
>> 210 empty_environment                             FAIL (line 45) 69:34
>> 341 multiple_version_committing                   FAIL (line 25) 0:01
>> 423 restricted_commit_with_inodeprints            FAIL (error creating
>> test directory) 0:00, 0:00 on CPU
>> 459 schema_migration                              FAIL (line 106) 0:12
>>
>> empty_environment has been failing for a while; the others are new. I
>> have not looked at them in detail yet.
>>
>
> All tests pass for me on Win32/MinGW.
>
> empty_environment needs to copy in all the DLLs that the monotone executable
> uses. It has a hardcoded list, which I'm guessing isn't quite right for your
> environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we
> could use to get the list right?
>
> I'd guess the others are probably issues with races and Windows' file
> locking...
>
>
> ___
> 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] Time for a release

[J Decker]

this is a small program I use to copy a program(or library) and all of
its related libraries which are not in %SYSTEMROOT% to a
destination...

http://sack.svn.sourceforge.net/viewvc/sack/src/utils/pcopy/

Unfortunatly it's got a few dependancies on other code in SACK - like
the routine that scans a directory for all files in it...

On Mon, Mar 8, 2010 at 6:11 AM, Timothy Brownawell  wrote:
> Stephen Leake wrote:
>>
>> The following tests are failing on Win32:
>>
>>  9 (normal)_netsync_on_partially_unrelated_revisions FAIL (error creating
>> test directory) 0:00, 0:00 on CPU
>> 210 empty_environment                             FAIL (line 45) 69:34
>> 341 multiple_version_committing                   FAIL (line 25) 0:01
>> 423 restricted_commit_with_inodeprints            FAIL (error creating
>> test directory) 0:00, 0:00 on CPU
>> 459 schema_migration                              FAIL (line 106) 0:12
>>
>> empty_environment has been failing for a while; the others are new. I
>> have not looked at them in detail yet.
>>
>
> All tests pass for me on Win32/MinGW.
>
> empty_environment needs to copy in all the DLLs that the monotone executable
> uses. It has a hardcoded list, which I'm guessing isn't quite right for your
> environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we
> could use to get the list right?
>
> I'd guess the others are probably issues with races and Windows' file
> locking...
>
>
> ___
> 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

[Monotone-devel] Failure to propagate...

[J Decker]

okay logs not attached.


-- Forwarded message --
From: J Decker 
Date: Thu, Mar 25, 2010 at 1:26 AM
Subject: Failure to propagate...
To: monotone-devel 


I started a branch a couple weeks ago, tonight I was going through the
trunk and cleaning obsolete projects and code, other than these
changes, the trees were recently propagated from trunk to the branch,
so there's just additional mods on the branch to the main.  But now,
after doing many drops, propagate just sits.

mtn.EXE: calculating left edit script on 67989 -> 112424 lines
·
When running with --debug option and capturing to a file, the above is
the last line in the file.

I'm attaching the logs, propagate.log is up to the point it hangs,
then when I hit ctrl C to end, a lot more information is logged, that
is attached in propagate-ctrlc.log


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

[Monotone-devel] Re: Failure to propagate...

[J Decker]

Left it running long enough, and it finally worked.  I'm not sure how
long it finally took.

On Thu, Mar 25, 2010 at 1:28 AM, J Decker  wrote:
> okay logs not attached.
>
>
> -- Forwarded message ------
> From: J Decker 
> Date: Thu, Mar 25, 2010 at 1:26 AM
> Subject: Failure to propagate...
> To: monotone-devel 
>
>
> I started a branch a couple weeks ago, tonight I was going through the
> trunk and cleaning obsolete projects and code, other than these
> changes, the trees were recently propagated from trunk to the branch,
> so there's just additional mods on the branch to the main.  But now,
> after doing many drops, propagate just sits.
>
> mtn.EXE: calculating left edit script on 67989 -> 112424 lines
> ·
> When running with --debug option and capturing to a file, the above is
> the last line in the file.
>
> I'm attaching the logs, propagate.log is up to the point it hangs,
> then when I hit ctrl C to end, a lot more information is logged, that
> is attached in propagate-ctrlc.log
>


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

[Monotone-devel] Question about mtn update --move-conflicting-paths

[J Decker]

mtn update --move-conflicting-paths works pretty good under windows
when I have updates that drop directories that are not empty.  Thank
you greatly for providing a method to work around this.

At the end of the update, the files and directories that caused the
paths to not be empty are left in _MTN/resolutions.

After a very long update, it might be nice to know that there are
folders left in _MTN/resolutions, I think this might be logged when
the command starts, but if you have a very long list of drops, there
is no notification at the end.

Bug? :The documentation from mtn update --help says "move conflicting,
unversioned paths into _MTN/conflicts before..." but there's nothing
in _MTN/conflicts... are conflicts then moved to resolutions?

and, I dunno, I'm kinda thinking that what's left over should be moved
back into the workspace after the drops are complete; though I did say
to drop the directory (and all tracked content)... ya, if I was
working in a sub-tree of a parent that was deleted, untracked work
should probably be saved in the workspace... but then, a stronger
notice should maybe apply to indicate that conflicting content from
the drop is left in _MTN/revisions, and you might want to move it out.


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

[Monotone-devel] Re: Question about mtn update --move-conflicting-paths

[J Decker]

I dunno, maybe a quick dump of what is untracked in _MTN/resolutions
at the end?  or a way to list that real quick?

move _MTN/resolutions .
mtn ls unknown resolutions

if contains other things than 'resolutions'  maybe move that stuff
back into the tree?  most of what was in the directory was temp files
(*.c~ ) .obj, and other ignored things.

maybe it's already doing this?


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

[Monotone-devel] Not sure where this error is from or why..

[J Decker]

This is the link of monotone on my system... I don't understand why
clock_gettime wouldn't be found seems to be in just 

g++  -march=native -Os -Wall -W -Wno-unused  -Wl,-s -o mtn sanity.o
simplestring_xform.o constants.o vocab.o charset.o paths.o
luaext_mkstemp.o luaext_parse_basic_io.o luaext_guess_binary.o
luaext_platform.o luaext_globish.o lua.o mkstemp.o file_io.o globish.o
basic_io.o mtn-sanity.o ui.o app_state.o automate_reader.o
cache_logger.o commands.o cmd.o cmd_netsync.o cmd_list.o cmd_packet.o
cmd_key_cert.o cmd_merging.o cmd_db.o cmd_diff_log.o cmd_ws_commit.o
cmd_othervcs.o cmd_automate.o cmd_files.o cmd_conflicts.o
diff_output.o lua_hooks.o transforms.o update.o work.o migrate_work.o
cert.o project.o outdated_indicator.o database.o key_store.o
ssh_agent.o keys.o packet.o rcs_file.o xdelta.o migrate_schema.o
migrate_ancestry.o refiner.o enumerator.o netsync.o
network/automate_session.o network/connection_info.o
network/listener_base.o network/listener.o network/make_server.o
network/netsync_session.o network/reactable.o network/reactor.o
network/session.o network/session_base.o network/wrapped_session.o
netxx_pipe.o netcmd.o merkle_tree.o lcs.o rcs_import.o git_change.o
git_export.o revision.o ancestry.o cset.o roster.o mt_version.o
automate.o database_check.o epoch.o gzip.o inodeprint.o selectors.o
annotate.o restrictions.o hmac.o merge_roster.o merge_conflict.o
merge_content.o merge_3way.o legacy.o uri.o graph.o roster_delta.o
sha1.o pcrewrap.o rev_height.o asciik.o dates.o package_revision.o
package_full_revision.o option.o options.o specialized_lexical_cast.o
monotone.o  unix/main.o std_hooks.o schema.o libplatform.a
lib3rdparty.a  -lpcre   -lbotan   -llua -lm   -lsqlite3   -lidn-lz

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libbotan.a(tm_posix.o):
In function `Botan::POSIX_Timer::clock() const':

tm_posix.cpp:(.text+0xa): undefined reference to `clock_gettime'

collect2: ld returned 1 exit status


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

[Monotone-devel] Net sync with 0.47 server fails...

[J Decker]

syncing with 0.47 server results on the client
mtn.EXE: warning: protocol error while processing peer :
'received network error: denied
'c64200903a4402fff7dcf6343d0290dfbecb5713' write permission for '*'
excluding '''

doing a quick serch for 'monotone sync 0.47' comes up with

http://osdir.com/ml/debian-bugs-dist/2010-03/msg06590.html

I had to modify my server's monontonerc to return true for
get_netsync_read_permitted and get_netsync_write_permitted...
otherwise, even though the key is listed as

if( identity == "u...@host.com" ) then return true end

it doesn't allow the user read or write permission.


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

Re: [Monotone-devel] Net sync with 0.47 server fails...

[J Decker]

Okay thanx - I usually read the release notes about what it takes to
upgrade, I guess I missed this note.   I had 0.45 running and it was
serving fine with the old rc

On Thu, May 6, 2010 at 4:03 AM, Stephen Leake
 wrote:
> J Decker  writes:
>
>> syncing with 0.47 server results on the client
>> mtn.EXE: warning: protocol error while processing peer :
>> 'received network error: denied
>> 'c64200903a4402fff7dcf6343d0290dfbecb5713' write permission for '*'
>> excluding '''
>>
>> doing a quick serch for 'monotone sync 0.47' comes up with
>>
>> http://osdir.com/ml/debian-bugs-dist/2010-03/msg06590.html
>>
>> I had to modify my server's monontonerc to return true for
>> get_netsync_read_permitted and get_netsync_write_permitted...
>> otherwise, even though the key is listed as
>>
>> if( identity == "u...@host.com" ) then return true end
>>
>> it doesn't allow the user read or write permission.
>
> See http://www.monotone.ca/docs/Hooks.html#Hooks section 6.1.1; it
> describes the format of a key_identity, which is now a table.
>
> So your test should be
>
> if( identity.given_name == "u...@host.com" ) then return true end
>
> or maybe identity.name
>
> This changed in 0.45
>
> --
> -- Stephe
>
>
> ___
> 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

[Monotone-devel] hello and thanx

[J Decker]

Nice to see lots of bugs squashed :)

I have to thank you for developing a sane product.   I have been
coerced into using mercurial at work, and after coming from monotone,
some of the things it makes me do are just insane.  Merge, for
instance, must be done through a workspace, so in order to just merge
two heads, If I had work in progress in the tree, I have to clone the
repository to another directory, check out the source(ya that's the
same step), and then do the merging;  A commit from a merge cannot be
done with relative paths like 'I want to commit just this part of the
tree', you have to commit the whole thing, so work in progress changes
would get mixed up in the whole thing.  The revisions to merge are all
in the repository, so why does it require a workspace?!  Git does the
same thing in this respect.

I dunno, this seems like such a small thing, but it pisses me off to
no end that I have to do so much extra work just to make sure that
sane merges happen.

Rebasing to another branch in mercurial and git are both very slow.

(coming from branch)
mtn update -r h:branch1  (takes like 3 seconds, 6 if i count the time
it scrolls text)
hg update -r h:branch1  (takes like a minute)

and there were more files changed in the mtn difference between
branches than were changes in mercurial.

git also gave me a huge hassle rebasing to another branch... I had
minor edits in the files, and it had no idea what to do with that...
and revert didn't work.. but that was a month ago, so the details of
my anger elude me.

Again, thanx, keep up the great work!

Wish you guys get a gui soon!  what with tortoise hg, git, and svn out
there (is there a tortoise bzr yet) ... should be easy enough to grab
one of those and tweak it to fit monotone.

Jim

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

[Monotone-devel] Failure to connect to IPV6 server

[J Decker]

Monotone has no ipv6 support?

It's something I've been implementing, and I had some firewall issues
otherwise, I can ping the IPV6 address, but monotone claims

mtn.EXE: network error: name resolution failure for
2001:db8:d:231::12: The requested name is valid, but no data of the
requested type was found. (11004)

(address changed to documentation prefix, and is literally not valid,
but, if the address was correct, it still fails to resolv.)

Linux uses 'inet_pton' for this translation, and Windows uses
'getaddrinfo' which works to resolve names and return the correct
address for literal addresses also.

for DNS resolution under linux, gethostbyname2() can be used to
resolve IPV6 and IPv4 addresses.

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

[Monotone-devel] A couple questions...

[J Decker]

Why does monotone read all revisions and certs in the database on a sync?

At least 90% of the time, a comparison between the heads of branches
to sync(A) vs the heads of branches to sync against(B) will result in
either A is before B or B is before A and occasionally neither A or B
is known to the respective opposite side, but then perhaps a revision
C could be stored per branch in the repository that A is in that is
the last point(s) [it may be multiple heads] that was known to sync...
then C will be before B in this third case.

probably less than 1% of synchronizations are new pulls, which would
require reading all revisions in the branches of interest.  (in which
case revision C will be blank or null).

I would think it would be a SIGNIFICANT reduction in sync time (which
isn't really that long for 30,000 revisions in assorted branches which
takes about 10 seconds to read on a netbook) to do a quick check and
just pull from the last known revision to the tip on both sides to
sync, instead of reading the entire revision structure.

Jim

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

Re: [Monotone-devel] A couple questions...

[J Decker]

On Thu, Jun 3, 2010 at 2:56 PM, Timothy Brownawell  wrote:
> On 06/03/2010 04:21 PM, J Decker wrote:
>>
>> Why does monotone read all revisions and certs in the database on a sync?
>
> One fairly basic feature monotone has is that certs can be added to
> arbitrarily old revisions. What this means for netsync is that just
> synchronizing the revision graph isn't enough, you also need to check
> information from every node.
>

Okay well that does explain that :)

>
> I think we don't want to store that kind of per-peer information just on
> general principle.

Yes, I can see that becoming complex, which is why I mentioned saving
it only on the client sync side, which is likely to have fewer remotes
than the central server side (which could have many identifiers for
the same client if the client is behind many firewalls and travels a
lot to various hotels, etc)... but on the client side probably only a
few servers are generally used to sync... a central or 3, and maybe a
couple peers...

even though it is a peer-to-peer operation, there is a side that plays
like a client, and a side that hosts service.

>
> What would probably work is to store a skip-list over the revision graph,
> and synchronize on first the leaves (well, probably near-leaves, say
> anything not covered by a higher skip-node) at each level and then either
> prune/iterate or just synchronize on all unknown-state revisions. The skip
> nodes could have a hash over all certs that they skip over.
>

But then you'd need to mark 'I definatly changed this revision way
back in history' ... but then when is that status cleared, since I may
have to push that to 3 servers

>> probably less than 1% of synchronizations are new pulls, which would
>> require reading all revisions in the branches of interest.  (in which
>> case revision C will be blank or null).
>
> Further, most pulls are going to have a few (or possibly no) new revisions
> on one side and no new revisions on the other. While it's fairly common that
> two people are commiting on the same branch at the same time, I think this
> is merely a significant minority of commits (and syncs).

true, since many branches in the overall sync are probably untouched.

>
>> I would think it would be a SIGNIFICANT reduction in sync time (which
>> isn't really that long for 30,000 revisions in assorted branches which
>> takes about 10 seconds to read on a netbook) to do a quick check and
>> just pull from the last known revision to the tip on both sides to
>> sync, instead of reading the entire revision structure.
>
> It's not quite that simple, but a graph-aware synchronization (with
> appropriate cert summarization) would definitely speed up figuring out what
> to send. It's on my to-do list somewhere, I promise. :)
>

Glad to hear that, sorry to hear that there are features that prevent
quick optimizations.

> --
> Timothy
>
> Free public monotone hosting: http://mtn-host.prjek.net
>

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

Re: [Monotone-devel] 0.48 rants

[J Decker]

Personally I always do my commits with   ...  -m "my message" ...  so
I doubt this even affects me in the least.

Though, I do concur with the vein of complaints, all other revisioning
control allow (expect?) that additional comments are put at the top of
the file.  How do you specify the cursor position when using
notepad.exe?

I haven't even seen a changelog example, I'd assume that it mostly
starts with MTN: Author:  etc... these should be
pretty easy to identify in any location, and I doubt that the
exactness of 'must be on 10th line' or 'must be after X and before ZZ'
would really be required



On Sat, Jul 17, 2010 at 2:03 PM, Aaron W. Hsu  wrote:
> Hey Everyone,
>
> With all the negative responses regarding the new changelog editor, I
> just thought I would weigh in with something a little more positive. I
> actually do like the changes, on a whole, and think that we shouldn't
> just revert to the old behavior.
>
> I did watch the discussion that went on when this feature went in, and I
> mostly agreed with how things were going, so I did not comment.
>
> I like that we have more changeable fields. The more the better in my
> mind. When I get something in a text editor, I like to think that
> whatever I will change will have some effect. I like that I can modify
> dates, branches, authors, and so forth. The problem with where to enter
> the changelog message really doesn't bother me so much, because we can
> always use editor's positioning arguments to put the cursor in the
> "right place" to start, and even without, we can allow for them to enter
> things at the top too.
>
> Actually, the "just start typing" methodology isn't really something I'm
> used to in most other programs. When I work with email for example, and
> I'm responding to a message in particular, I don't start typing at the
> top except to put a little header in, at most. So this doesn't really
> bother me.
>
> I do like that the formatting for these types of displays was
> normalized. We could get rid of some redundant information, which
> wouldn't be a bad thing, but I do like that I can "preview" my commit in
> a sense.
>
> As a question, can I alter what is committed through the changelog
> editor? At the moment, it does not seem like I can. That is one feature
> I would like. Normally, my workflow goes something like: status to see
> what has changed; diff to see those individual changes; a series of
> commits to commit the pieces in the way that I want. For those last
> pieces, it would be nice if I could just type 'mtn commit' and then edit
> my message to select what will be committed and what will not, and to
> what branch, and so forth. I like the idea of doing this in my editor.
> AT the moment, when I tried to do this, it didn't seem to work, and gave
> me some hoohah about the commit failing.
>
> So, overall, I'm happy with this change, and while we could make some
> adjustments to it, I do think that there is a great deal of positive
> about this new changelog editor that I would like to keep around.
>
>  Aaron W. Hsu
>
> ___
> 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

[Monotone-devel] SCCS interface Support

[J Decker]

there's a 'standard' that was developed to interface, generically, version control systems and development environemnts for instance Visual Slick Edit, Visual Studio... SCCS Support would be a nice addition to see for Monotone.

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

Re: [Monotone-devel] Re: SCCS interface Support

[J Decker]

Yes, My deepest apologies ... MSSCCI though I can't find the link right now to the good informationOn 6/30/06, Steven E. Harris <
[EMAIL PROTECTED]> wrote:Thomas Keller <[EMAIL PROTECTED]
> writes:> I second the request for a "general" interface to other VC systems,> and I know that PVCS, ClearCase and some other still use the SCCS> format internallyI think the OP was referring to MSSCCI¹, or Microsoft Source Code
Control Inteface, not SCCS.Footnotes:¹ Sometimes abbreviated incorrectly as MSCCI, SCCI, or MSCI.--Steven E. Harris___Monotone-devel mailing list
Monotone-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/monotone-devel

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

[Monotone-devel] Path already exists, failure to create!

[J Decker]

Okay I just went though a huge nightmare of an update...first update, some path to create already existed, and monotone complained that could not create it.I moved that path away from beign in the way, and tried to update again.
directories and files were left in _MTN/tmp which I had to get rid of...then the directories which had already succeeded in being created in the update existed, and monotone again complained that directoreis existed it could not be updated (these were updated before it got to the final destination that existed in the first place)
So I removed those, (after tracking them all down, and trying to be careful so as to not lose changes in other files around the same location)I ended up going through the update, remove some directoreis, clean _MTN/tmp about 5 times before I got this tree updated all because there was originally a directory that existed that could not be created - it wasn't even the case that some file existed in the place of a directory, the directory itself did exist
This is all in 0.27 windows binary build.Although I am liking not having to be in the root of the working directory (with no processes (such as visual studio) locking other directories) and being able to update from pretty much anywhere in the working directories under windows now, I notice that things left in _MTN/tmp are not properly destroyed (or reveted back to their original location) under windows.
Jim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Unresolved conflict, want to back out...

[J Decker]

I have several branches.branch A is the 'trunk'branch B is one evolution from the trunkbranch C is a descendnat of branch A with a specific 'pluck' of changes between A and B applied .branch D is another development path of A
mtn propagate branch.c branch.a  (update A to be the head of C with plucked changes)mtn propagate branch.a branch.dSome additional details, if they help... )Earlier I syncrhonized B and D to A's changes... 
mtn propagate branch.a branch.dmtn propagate branch.d branch.bmtn update -r h:branch.amtn pluck -r h:branch.a -r h:branch.b(revert several branch specific changes)mtn commit --branch=branch.C #creates branch C)
mtn propagate branch.c branch.amtn propagate branch.a branch.dmtn.EXE: [source] 6c5472831fe23406d9107638185f72d7eb96c9e0mtn.EXE: [target] 530d500ad40b790d2ea1b0986fe1372032434863mtn.EXE: warning: rename target conflict: nodes 2117, 2081, both want parent 1442, name dealer_editor
mtn.EXE: warning: resolve non-content conflicts and then try again.mtn.EXE: error: merge failed due to unresolved conflictsI guess branch.d added a thing called dealer_editor, which was then propagated to C, but was still not part of A, applying the pluck resulted in the addition again and commiting into C
I'd like to undo a propagate into the branch branch.a from branch.c which was'up to date with respect to... placing rev in branch' (or whatever the message actually was)so now mtn head branch.a
mtn head branch.c (both have the same Rev ID)I'd like to unwind the propagate from branch.c to branch.a- and/or - I'd lilke to fix branch.a so I can propagate to branch.b or branch.d 
-A related complaint at this point I cannot usemtn update -r h:branch.a mtn update -r h:branch.c
to change branches, because the reve is a member of both, the 'branch' indication in _MTN bookkeeping directory is not updated.-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Unresolved conflict, want to back out...

[J Decker]

Here is a batch file which accomplishes the same thing I did.It creates a temp .db using mtn it generates a key called 'junk' which it sets up for itself.It starts by deleting the temp directory 'x' and the database '
temp.db' then starts fresh every time. Begin test.bat rmdir /s xdel temp.dbmtn --db=temp.db db initmtn --db=temp.db genkey junkmkdir xmtn --db=temp.db --key=junk --branch=branch.a
 setup xcd xecho "Branch A" >filemtn add filemtn commit -m "Initial commit branch A" mkdir pathcd pathecho "branch a path1" >file2mtn add file2mtn commit -m "Initial commit branch B" --branch=
branch.bcd ..mtn update -r h:branch.amtn headmkdir path2cd path2echo "branch C path 2 file 1" >file3mtn add file3mtn commit -m "Initial commit branch C" --branch=branch.c
mtn propagate branch.b branch.ccd ..mtn update -r h:branch.aecho "New Branch A" >>filemtn commit -m "Updated branch A, begin propagate." mtn propagate branch.a branch.b
mtn propagate branch.b branch.cmtn pluck -r h:branch.a -r h:branch.bmtn commitmtn propagate branch.a branch.cecho --- The above line failed.--- goto done.mtn propagate branch.b branch.c
:done- Done Test.bat 
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Unresolved conflict, want to back out...

[J Decker]

Dealer_editor is a directory.  It exists within the same location in both versions (or would) ... full path is something like src/apps/milk/dealer_editorOn 10/26/06, 
Brian May <[EMAIL PROTECTED]> wrote:
>>>>> "J" == J Decker  writes:J> mtn.EXE: [source] 6c5472831fe23406d9107638185f72d7eb96c9e0J> mtn.EXE: [target] 530d500ad40b790d2ea1b0986fe1372032434863J> 
mtn.EXE: warning: rename target conflict: nodes 2117, 2081, both want parent 1442, name dealer_editorJ> mtn.EXE: warning: resolve non-content conflicts and then try again.J> mtn.EXE: error: merge failed due to unresolved conflicts
Is dealer_editor a file or a directory?I think the merge UI isn't yet good enough to do what you want, butthere are some workarounds:* delete dealer_editor in one on the branches.* rename dealer_editor in one of the branches, merge, and then fix up.
i.e. remove the source of the conflict before doing the merge.(I haven't read you email in detail so I apologise if I got somethingwrong).Another problem with the above message is, AFAIK, it doesn't really
say what file has a problem - so if you have two different directories(with different parents) called dealer_editor, it is not easy to workout which one it is referring to.--Brian May <
[EMAIL PROTECTED]>
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] ViewMTN 0.06 released

[J Decker]

This looks a little better, but I would like the old ooption of showing more/less (espcecially ALL) revisions on a branch, such a minimal view is sometimes very hard to see how the merges have actually happpened.
On 10/26/06, Grahame Bowland <[EMAIL PROTECTED]> wrote:
Hi guysJust a quick note to say that ViewMTN 0.06 is out. Several minor bugswere found during testing of the last "preview"; in particular, 0.06works correctly with newer versions of Cheetah templates, and I've
ensured it still works with old versions.Grab it from the ViewMTN site:http://grahame.angrygoats.net/viewmtn.shtmlIf there are any bugs or feature requests, just let me know.
CheersGrahame___Monotone-devel mailing listMonotone-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: recursivity (was Re: [Monotone-devel] Questions pertaining Eclipse Integration)

[J Decker]

I doubt anyone wants "commit ." or "diff ." to be interpreted
non-recursively (at least without some sort of --non-recursive flag).Is this a compelling argument for add/drop to behave the same way?Is there a flag to do this?  I wanted to do those, and pluck . to just handle that particular directory.  
There are plugin directories under the main that I had changes in that I certainly did not want commited, the developers claim under there that if I touch it I own it. 
-- Nathaniel--In mathematics, it's not enough to read the wordsyou have to hear the music___Monotone-devel mailing list
Monotone-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Steps to break propagation....

[J Decker]

Attached is a batch that creates a folder called project1, goes into it, creates a db with some junk key, makes some branches, adds some files, does some commits, and at the end fails.Basically I've been maintaining a branch that developers develop on, on one side, and made a branch specifically to handle SVN synching.
At some point, I updated the repository from SVN, and commited it into monotone... svn update, mtn drop --missing, mtn add --unknown, mtn commit. --- this is where I messed up... 
I then wanted those changes on the main development branch that we use, so I propagated the svnsync to the mainline branch.then I updated the mainline branch and attempted to compile the code... but there were many incomplete changes in the svn repository at that time...
so I wanted to back out the propagate (which was a case of  mtn: no merge necessary; putting 1f04277a396a7633c997309b26e6e7a03cfc4977 in branch 'branch1', for isntance)I then applied the disapprove command on that head in the mainline branch, and updated to get back to a working state.
now, later, I updated the svn branch, and attempted to propagate the changes ot the main branch, but the disapproval included removing some additional directories/files that were added in the first case... so now, they still exist in the svn branch, and should exist now...
Instead of 'disapprove' what if there was a sort of 'defer' command to act like a disapproval, and unwind the changes made, but when it comes time to re-propagate or re-merge the code, it doesn't have any sort of authority... or something...
set KEY=[EMAIL PROTECTED]mtn --db=junk.db db initmtn --db=junk.db genkey %KEY%mkdir branch1mkdir branch2mtn --db=junk.db --branch=branch1 --key=%KEY% setup branch1
cd branch1echo "trunk" >filemtn add filemtn commit -m "add first file"cd ..cd branch2mtn --db=../junk.db --branch=branch1 --key=%KEY% co .echo "branch mod 1" >> file
mtn commit -m "Modify a file on branch" --branch=branch2echo synchronize branch1 with branch2mtn propagate branch2 branch1cd ..cd branch1mtn updateecho "do some more work" >>file
mtn commit -m "Update common working branch"cd ..mtn --db=junk.db propagate branch1 branch2 --key=%KEY%cd branch2mtn updateecho "external branch mod" >>filemkdir test1
cd test1echo "extra file goes here" >file2mtn add file2mtn commit -m "Added a file... perhaps some other mods"cd ..cd ..mtn --db=junk.db propagate branch2 branch1 --key=%KEY%
:: at this point, the changes made to branch2 cause the build to break badly all over the place: I want to undo the propagation from branch2 to branch1mtn --db=junk.db --branch=branch1 head
echo will disapprove 1f04277a396a7633c997309b26e6e7a03cfc4977mtn --db=junk.db --branch=branch1 disapprove 1f04277a396a7633c997309b26e6e7a03cfc4977 --key=%KEY%:cd branch2cd test1echo "Add another file to propagate later" >file3
mtn add file3mtn commit -m "Added more stuff to sync branch"cd ..: failure heremtn propagate branch2 branch1cd ..


whatidid.bat.dontrunme
Description: Binary data
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: line endings with 0.31

[J Decker]

The logic for determining line endings within reasonable limits is entirely
feasible in practice as well as theory.

On 11/21/06, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote:


I've been thinking about this issue a number of times, and have
discussed it as well.

A thought that came to my mind a while ago was that we could really
make this really simple:

- always store the file unchanged, and for text files (according to
   some criteria), store the local EOL format in an attribute.
   mtn:eol = CR, mtn:eol = LF or mtn:eol = CRLF
- for text files, always convert to the local EOL format on
   extraction.
   So if something was stored with mtn:eol = CR (on a Mac, typically),
   all CRs would be converted to LF on a Unix system, or to CRLF on a
   Windows system.

One might wonder what happens during a merge of two revisions where
the same file is stored with different EOL formats in the different
revisions.  Quite simple, since they get converted to the local format
on extraction, I'm assuming that what's merged is the result after
extraction.

Now, please, before you start reacting, I *know* that the whole file
isn't stored, only the delta.  Unfortunately, I know diddly over squat
about xdelta, so a question is if storing different EOL formats at
different times creates more trouble than it's worth.

On the plus side, it means that storing a file (or the delta) will
always happen without conversion, whether it's binary or text, and the
user can remember to add the EOL attribute as an afterthought, at any
time.

If we would do this rigorously, we wouldn't need any hooks either,
really, unless someone really wants to override the default function.

Now, the next, and somewhat related thing (or can of worms) is
character code conversion.

Cheers,
Richard

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis


___
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: line endings with 0.31

[J Decker]

I have to state a vote.

I had lengthy discussions with CVS on similar topics, and resorted to
hacking my own CVS to work properly, that is, if a text file has \r\n, keep
\r\n, do not convert to \r\r\n.
If a text file has \r or \n in some sequence [\r\n]* this is an end of line,
if \n's exist multiply, there are blank lines.  (unless you're on a MAC that
uses \r for newlines?!)

If a file is checked in and developed by a developer which is using both
windows and linux, her tools will of course support both cases for files in
both environments which must be developed in either.

There is little requirement for conversion, and eventually, conversion is
self recursive.

On a note from some windows programmer that appreciated the conversions when
checking out linux-like sources to have 'notepad' work as a browser; While
some days I can agree, in the end, one must make sacrifices and call a goat
a goat, and know that you need to use a smarter tool than notepad to deal
with text files.

Linux tools rarely care about the presence or absence of \r's... they're
redundant other than the classic teletype need to send a carriage return
before the line feed.  If you sent the line feed first, then the carriage
return wouldn't have enough time to happen before processing a the next
character, and the letter would strike before the head reached the return
point.  Sometimes I wonder if people actually learn from history at all...
Modern equipment rarely even requires a carriage return, being of a digital
nature, you cannot gain cheap effect like BOLD by sending
'BOLD\rBOLD\rBOLD really ...' to a printer device... thermal and laser
printers will not gain any effect because there is no ribbon.

I actually cannot think of a sane reason that I would ever want a line feed
without returning to the start 

In the end, I'm sure everyone will disagree, the developers will say it
works good enough, and it'll remain broke, lest the break what already works
fixing something that isn't broken.

Unless you expect users to be lame and use notepad to edit text files, never
open a file with fopen("file", "t" );  but always specify the flag
fopen(file, "b");  even under linux environments this does not hurt.  If you
mean text, say text, always read binary and disregard \r as whitespace.
disregard also \n as whitespace.

Nothing seems to have a problem not converting tab charaters into spaces.

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

Re: [Monotone-devel] Re: line endings with 0.31

[J Decker]

edit and wordpad work for builtin stuff

I have been using FTE ( http://fte.sourceforge.net/ ) for the last several
years... it shows the carriage return character... visual studio, actually
the only one that doesn't behave well is notepad

On 11/22/06, Brian May <[EMAIL PROTECTED]> wrote:


>>>>> "J" == J Decker  writes:

J> On a note from some windows programmer that appreciated the
J> conversions when checking out linux-like sources to have
J> 'notepad' work as a browser; While some days I can agree, in
J> the end, one must make sacrifices and call a goat a goat, and
J> know that you need to use a smarter tool than notepad to deal
J> with text files.

Any there any sane editors for Windows that only support DOS text file
format?

(no - I do not consider notepad a sane editor anymore).
--
Brian May <[EMAIL PROTECTED]>


___
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: Re: Why does pull require -k?

[J Decker]

On 12/15/06, Boris <[EMAIL PROTECTED]> wrote:


Matthew Gregan wrote:
> At 2006-12-14T17:33:01-0500, Boris wrote:
>> Okay, makes sense to me. But is there a way to set a default key (for
>> example with one of the variables)?
>
> You can put the key ID into _MTN/options.  There's no good UI to do
> so at the moment, so you'll need to do it manually using a text
> editor.
>
> key "[EMAIL PROTECTED]"

Thanks, perfect!



(wow gmail sucks for replying to this list)
It does write the key there on either setup or checkout.


Boris






___
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

[Monotone-devel] Possible bug, a conversation about branching and propagation.

[J Decker]

I have recently desired to take my many branches and consolidate them into a
larger more co-hesive project such that it may be easier for people to work
with.

I have used, with much confusion and difficulty, a structure such as
work/_MTN (branch1)
work/project1/_MTN(branch1.project1)
work/project2/_MTN(branch1.project2)

work/project1/test1/_MTN(branch1.project1.test1)
work/project1/test2/_MTN(branch1.project1.test2)

where work contains branches project1 and project 2 as granted by
mtn merge_into_dir branch1.project1 branch1 project1
mtn merge_into_dir branch1.project2 branch1 project2

mtn merge_into_dir branch1.project1.test1 branch1.project1 project1/test1
mtn merge_into_dir branch1.project1.test2 branch1.project2 project1/test2

okay that's all ugly, and certainly is not clear...

having them all checked out at once, allowing local commits to
branch1.project1.test1 which can be propagated to branch1.project1


Okay that's really not workable in the grand scheme... and you end up with
3way merges all over since sometimes the changes within work/project1/test1
would get commited directly into branch1, instead of the correctly merged
sub-tree...


-

What I did today that failed. (Wish I had some notation here)

-> means that a thing was propagated
| means that a thing was branched
<- means pivot_rooted

org.d3x0r.sack | org.d3x0r.sack.plusplus | org.d3x0r.sack.c#
org.d3x0r.dekware
org.d3x0r.games

org.d3x0r.sack -> org.d3x0r.trunk/work/sack
org.d3x0r.dekware -> org.d3x0r.trunk/work/dekware
org.d3x0r.games -> org.d3x0r.trunk/work/games

which then org.d3x0r.trunk becomes a collection of all previosly poritioned
out projects, which may now safely depend on each other while still
maintaing their own identity.

(this is what I wanted I guess in my ideal world)


From this state, I can propagate org.d3x0r.trunk -> org.d3x0r.sack or

org.d3x0r.dekware and only those files that originated in that branch are
propagated.

(in reality)
org.d3x0r.sack -> org.d3x0r.dekware fails, as both have root nodes that
conflict.

propagation of org.d3x0r.trunk -> org.d3x0r.sack provides a rename of the
root directory to the path provided with the merge_into_dir and dekware and
trunk are in sync, and no merge is nessecary.
[now org.d3x0r.sack -> org.d3x0r.dekware is possible]


This is all so dangerous to do...

I don't always want to have the coagulated project, but I would like to
propagate changes made there... I suppose I could re-pivot-root delete the
old root, commit to a related branch, and propagate that branch back to the
original source to get the updates back out correctly...

mtn -e pivot_root sack delete; mtn -Re rm delete; mtn commit -m "Updated
changes" -b org.d3x0r.trunk.sack
mtn propagate org.d3x0r.trunk.sack org.d3x0r.sack

but I think that that will cause a great deal of excessive information
beyond just a simple merge...
I guess all the deleted file entries from the restoration of .sack from
.trunk (.trunk.sack), will only exist once...
but I do then have to remember
org.d3x0r.trunk->org.d3x0r.trunk.sack->org.d3x0r.sack
... the reverse is easy
 org.d3x0r.sack -> org.d3x0r.trunk
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: a conversation about branching and propagation.

[J Decker]

Oops, forgot to change the subject.

On 1/4/07, J Decker <[EMAIL PROTECTED]> wrote:



I have recently desired to take my many branches and consolidate them into
a larger more co-hesive project such that it may be easier for people to
work with.

I have used, with much confusion and difficulty, a structure such as
work/_MTN (branch1)
work/project1/_MTN(branch1.project1)
work/project2/_MTN(branch1.project2)

work/project1/test1/_MTN(branch1.project1.test1)
work/project1/test2/_MTN(branch1.project1.test2)

where work contains branches project1 and project 2 as granted by
mtn merge_into_dir branch1.project1 branch1 project1
mtn merge_into_dir branch1.project2 branch1 project2

mtn merge_into_dir branch1.project1.test1 branch1.project1 project1/test1
mtn merge_into_dir branch1.project1.test2 branch1.project2 project1/test2

okay that's all ugly, and certainly is not clear...

having them all checked out at once, allowing local commits to
branch1.project1.test1 which can be propagated to branch1.project1


Okay that's really not workable in the grand scheme... and you end up with
3way merges all over since sometimes the changes within work/project1/test1
would get commited directly into branch1, instead of the correctly merged
sub-tree...


-

What I did today that failed. (Wish I had some notation here)

-> means that a thing was propagated
| means that a thing was branched
<- means pivot_rooted

org.d3x0r.sack | org.d3x0r.sack.plusplus | org.d3x0r.sack.c#
org.d3x0r.dekware
org.d3x0r.games

org.d3x0r.sack -> org.d3x0r.trunk/work/sack
org.d3x0r.dekware -> org.d3x0r.trunk /work/dekware
org.d3x0r.games -> org.d3x0r.trunk/work/games

which then org.d3x0r.trunk becomes a collection of all previosly
poritioned out projects, which may now safely depend on each other while
still maintaing their own identity.

(this is what I wanted I guess in my ideal world)

From this state, I can propagate org.d3x0r.trunk -> org.d3x0r.sack or
org.d3x0r.dekware and only those files that originated in that branch are
propagated.

(in reality)
org.d3x0r.sack -> org.d3x0r.dekware fails, as both have root nodes that
conflict.

propagation of org.d3x0r.trunk -> org.d3x0r.sack provides a rename of the
root directory to the path provided with the merge_into_dir and dekware and
trunk are in sync, and no merge is nessecary.
[now org.d3x0r.sack -> org.d3x0r.dekware is possible]


This is all so dangerous to do...

 I don't always want to have the coagulated project, but I would like to
propagate changes made there... I suppose I could re-pivot-root delete the
old root, commit to a related branch, and propagate that branch back to the
original source to get the updates back out correctly...

mtn -e pivot_root sack delete; mtn -Re rm delete; mtn commit -m "Updated
changes" -b org.d3x0r.trunk.sack
mtn propagate org.d3x0r.trunk.sack org.d3x0r.sack

but I think that that will cause a great deal of excessive information
beyond just a simple merge...
I guess all the deleted file entries from the restoration of .sack from
.trunk (.trunk.sack), will only exist once...
but I do then have to remember
 org.d3x0r.trunk->org.d3x0r.trunk.sack->org.d3x0r.sack
... the reverse is easy
  org.d3x0r.sack -> org.d3x0r.trunk





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

[Monotone-devel] Monotone update lost deletions

[J Decker]

I cleaned up this branch quite some time ago.  After upgrading the database,
it's complaining that files that were removed are missing.

What further information can I give?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Monotone update lost deletions

[J Decker]

No, sorry, it was actually a WIP...

On 1/25/07, Nathaniel J. Smith <[EMAIL PROTECTED]> wrote:


On Thu, Jan 25, 2007 at 08:16:56AM -0800, J Decker wrote:
> I cleaned up this branch quite some time ago.  After upgrading the
database,
> it's complaining that files that were removed are missing.
>
> What further information can I give?

You upgraded from what to what?  What upgrade commands did you run?
What commands are complaining about missing files?  What is the
contents of your _MTN/work file?

-- Nathaniel

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

[Monotone-devel] Oh what a tangled web we weave...

[J Decker]

problem of the day

I have several branches.

branch1 - the base branch that everything started from.

Branch2 - a branch containing branch1 which has been merged into a
directory.

branch3 - a workspace that resembles branch1, but is branch2 with a pivoted
root to the base directory.

In the process of development I added a file to branch2.  With time, changes
to branch3 need to be merged into branch1, however, this will break the
merge_into_dir merge from branch1 into branch2 on the next propagate... I
already made the mistake of attempting to propagate branch3 back to branch2,
thereby destroying everything else that has also been merged into various
directories.So, back to where I was, in branch2 I added a file.
Manually applying the changes from branch3 to branch1, I needed the same
header.. since I cannot get this header by propagation, I went ahead and
just added it to branch1...

and now, I get a rename target conflict attemtping to propagate from branch1
to branch2...

1) how can I fix this?  can I do something that causes a drop of the new
file during the propagation?  Can I cause a rename to some other file (which
can subsequently be dropped) to happen propagating from branch1 to branch2 ?

(wonder if pluck could have been used to apply the changes... somehow I
think that pluck does not exactly resemble merge/propagate)

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

[Monotone-devel] Monotone revision updates, minor feature requests

[J Decker]

With the latest updates, the cert counter counts like mad which is great and
all, but I suspect that the update of the display is taking more time than
the actual counting/reading of the certs... the digits up to thousands
update at an unreadable speed... Perhaps a simple timer that can check to
see if like 100ms has elapsed and then update the display would be a nice
generic solution to this update...

Some silly things... if I'm in a workspace, why can't I just type 'mtn
serve' and use the default key/database specified in the workspace?

It seems that mtn add --unknown is now broken under windows.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Monotone revision updates, minor feature requests

[J Decker]

> It seems that mtn add --unknown is now broken under windows.

Can you be more specific?  It seems to work for me and the testsuite.



Honestly I'm not sure - a couple people tried adding files and I said mtn
add *, they said that didn't work... and mtn add  didn't add
all the files in the directory... another one was attempting to use
--unknown and there were no files added even though mtn ls unknown showed
the files that were not yet tracked...  (we do have a .mtn-ignore file that
disregards things like debug, *.ncb, and other temp files that visual studio
uses, but I'd imagine that if they shoed up with mtn ls unknown, that they
should also have been added... but he had to speciy each file ) but it's
over now, so I don't know exact parameters of this, and it's hear-say.


Cheers,

-mjg
--
Matthew Gregan |/
 /|[EMAIL PROTECTED]


___
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] linus talk on git

[J Decker]

Harsh  (also beware of falling rants)

Unforutnatly, although monotone has become much much better for performance
issues... it was knocked out of the world of 'valid' distributed version
control systems because of speed.

There may be some issues with 'guarantee that what I put in I get back out'
also, in respect to line endings I know there was some discussion about
monotone being 'helpful' with line ending translation, which it really
shouldn't do...

There may be reasons that no matter what platform I check a certain text
file out on that the line endings need to be exactly what I put in.

And more likely, if your sources, your compiler, etc, require certain line
endings, then store them that way.  And probably, noone else with any other
sort of plaformtn sorry I'm rambling.


Git's command set appears, on the surface, to resemble monotone's GPM is
one such project that has become involved with 'git' but it's very unclear
how to actually use git to get these sources... maybe it's cause I started
with that specific project...


On 5/17/07, Evan Martin <[EMAIL PROTECTED]> wrote:


Linus Torvalds gave a talk at Google on git:
http://www.youtube.com/watch?v=4XpnKHJAok8
It's not that great of a talk (sorta slow and rambly), but I thought
I'd point out to y'all that he says a few nice things about monotone
right around minute 12.  (Seeking on YouTube rarely works, but I've
found that if you let the video buffer past the 12 minute point you'll
sometimes be able to jump to that point by clicking.)


___
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] linus talk on git

[J Decker]

monotone absolutely does not convert line endings, charsets, or anything
else by default.  What you put into the system is exactly what you get
out.

There used to be an option to enable line ending and charset conversions,
it
was off by default, it never particularly worked well, and there wasn't
much
evidence that it was even used, so it was completely removed in 0.33.




That is most excellent!  I am so very very happy to hear that.

(Guess my only remaiing culprit is Visual studio reacting to mixed-moded
line endings and converting the wrong direction :)

\r\r\r\n makes for horrible line endings.

Jim

Cheers,

-mjg
--
Matthew Gregan |/
 /|[EMAIL PROTECTED]


___
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] linus talk on git

[J Decker]

On 5/18/07, Justin Patrin <[EMAIL PROTECTED]> wrote:


On 5/18/07, Matthew Gregan <[EMAIL PROTECTED]> wrote:
> At 2007-05-18T04:13:31-0700, J Decker wrote:
> > There may be some issues with 'guarantee that what I put in I get back
> > out' also, in respect to line endings I know there was some
discussion
> > about monotone being 'helpful' with line ending translation, which it
> > really shouldn't do...
>
> monotone absolutely does not convert line endings, charsets, or anything
> else by default.  What you put into the system is exactly what you get
out.
>
> There used to be an option to enable line ending and charset
conversions, it
> was off by default, it never particularly worked well, and there wasn't
much
> evidence that it was even used, so it was completely removed in 0.33.
>

Yes, I thought I remembered this at the summit. I fully agree with
Linus here. What I put in should be what I get out. Platform-specific
line-endings should be done away with and/or text editors should be
able to deal with any type of line ending.

Then again, some people (*cough* MS *cough*) don't play well with
others. In cases where you need a specific line ending and it's
different than in the repo I'd suggest allowing some kind of lua
hooks, with some examples which show people how to do things in the
least destructive manner.




I dunno... only MS thing that really fails badly is notepad but then who
edits code in notepad?  I think that tab doesn't even work there...

certain THE MS tool Visual Studio has no difficulties


--

Justin Patrin


___
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

[Monotone-devel] I think this behavior might be wrong....

[J Decker]

I was doing some work, and decided that I wanted to commit that work to a
new branch, so as to not distrub other developers too badly... I still
haven't completely tested the changes, but it turns out that the changes
were included in the main branch anyhow because I then made some other
changes to files and commited them against the main branch, without first
updating to that branch.  At the time I wondered if monotone would be really
smart about the thing that I did, but as it turns out, the branch tag I
applied to the revision basically made no difference...

This is a script which reproduces effectively what I did.  What I would have
expected in the final checkout would have been 'file' with content 'Branch1'
and 'file2' with content 'branch1'.  Instead, I get 'file' with content
'branch1 + branch2' but I did not propagate the branches... so I would not
have expected the changes to be merged...

Maybe an artificial warning/error can be generated to alert the user that
such a thing will not produce what they might expect?



mtn --db=test.db db init
mtn --db=test.db genkey temp

mtn --db=test.db --key=temp --branch=branch1 setup .

echo "Branch1" >file
mtn --db=test.db --key=temp  add file
mtn --db=test.db --key=temp  commit -m "Begin branch1"

echo "+Branch2" >>file
mtn --db=test.db --key=temp --branch=branch2 commit -m "Changed file, begin
branch2"

echo "branch1" >file2
mtn --db=test.db --key=temp add file2
mtn --db=test.db --key=temp --branch=branch1 commit -m "Add a file to
branch1"

mkdir checkout
cd checkout
mtn --db=../test.db --key=temp --branch=branch1 co .



---



Again, I was working on 'branch', made changes I didn't want to share with
the public yet and commited changes on --branch='branch.test'.  I then
modified other code, and commited that code using --branch='branch' to
commit it against the main branch instead of branch.test.  But at the end,
the changes added to branch.test were included in 'branch' automatically...
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: I think this behavior might be wrong....

[J Decker]

Okay - Along this same topic.  This is very very very annoying.

So I got all done, branch.test was up to date with branch.  and vice versa.

(current workspace is on branch.test)

mtn update -r h:branch

mtn.EXE: expanding selection 'h:[branch]'
mtn.EXE: expanded to '908a782fdccba6caea8ccf06416a982628b93ee9'
mtn.EXE: already up to date at 908a782fdccba6caea8ccf06416a982628b93ee9

the next commit
mtn.EXE: beginning commit on branch 'branch.test'


It would be really nice if the current branch tag in _MTN/options would
update even if the revision is already up to date.


On 5/22/07, J Decker <[EMAIL PROTECTED]> wrote:



I was doing some work, and decided that I wanted to commit that work to a
new branch, so as to not distrub other developers too badly... I still
haven't completely tested the changes, but it turns out that the changes
were included in the main branch anyhow because I then made some other
changes to files and commited them against the main branch, without first
updating to that branch.  At the time I wondered if monotone would be really
smart about the thing that I did, but as it turns out, the branch tag I
applied to the revision basically made no difference...

This is a script which reproduces effectively what I did.  What I would
have expected in the final checkout would have been 'file' with content
'Branch1' and 'file2' with content 'branch1'.  Instead, I get 'file' with
content 'branch1 + branch2' but I did not propagate the branches... so I
would not have expected the changes to be merged...

Maybe an artificial warning/error can be generated to alert the user that
such a thing will not produce what they might expect?



mtn --db=test.db db init
mtn --db=test.db genkey temp

mtn --db=test.db --key=temp --branch=branch1 setup .

echo "Branch1" >file
mtn --db=test.db --key=temp  add file
mtn --db=test.db --key=temp  commit -m "Begin branch1"

echo "+Branch2" >>file
mtn --db=test.db --key=temp --branch=branch2 commit -m "Changed file,
begin branch2"

echo "branch1" >file2
mtn --db=test.db --key=temp add file2
mtn --db=test.db --key=temp --branch=branch1 commit -m "Add a file to
branch1"

mkdir checkout
cd checkout
mtn --db=../test.db --key=temp --branch=branch1 co .



 ---



Again, I was working on 'branch', made changes I didn't want to share with
the public yet and commited changes on --branch='branch.test'.  I then
modified other code, and commited that code using --branch='branch' to
commit it against the main branch instead of branch.test.  But at the end,
the changes added to branch.test were included in 'branch'
automatically...







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

Re: [Monotone-devel] I think this behavior might be wrong....

[J Decker]

On 5/22/07, Richard Levitte <[EMAIL PROTECTED]> wrote:


What you're missing in the whole thing is the ancestry.  You see, with
your last commit (which is to branch1), you're using the previous
commit (which is in branch2) as ancestor, so even if you're not doing
a propagate, you are producing a history that goes back and forth
between the branches.



Yes I understand that if i had updated it would have fixed the issue.  and
at the time I did the commit I thought about doing an update ... except I
knew that the other branch already had split heads, and didn't really want
some of the other changes merged inot my current code at that moment
isn't there a way to say like 'commit this agains the head of the branch?'
oh - except as I just said there' were aready 2 heads so ...




To do what you ask for, you need to do an update in the middle, so it

looks like this:

mtn --db=test.db db init
mtn --db=test.db genkey temp

mtn --db=test.db --key=temp --branch=branch1 setup .

echo "Branch1" >file
mtn --db=test.db --key=temp  add file
mtn --db=test.db --key=temp  commit -m "Begin branch1"

echo "+Branch2" >>file
mtn --db=test.db --key=temp --branch=branch2 commit -m "Changed file,
begin branch2"

# THIS IS THE MISSING PIECE
mtn --db=test.db --key=temp --revision=h:branch1 update

echo "branch1" >file2
mtn --db=test.db --key=temp add file2
mtn --db=test.db --key=temp --branch=branch1 commit -m "Add a file to
branch1"

mkdir checkout
cd checkout
mtn --db=../test.db --key=temp --branch=branch1 co .

In message <[EMAIL PROTECTED]>
on Tue, 22 May 2007 01:24:51 -0700, "J Decker" <[EMAIL PROTECTED]> said:

d3ck0r> I was doing some work, and decided that I wanted to commit that
work to a
d3ck0r> new branch, so as to not distrub other developers too badly... I
still
d3ck0r> haven't completely tested the changes, but it turns out that the
changes
d3ck0r> were included in the main branch anyhow because I then made some
other
d3ck0r> changes to files and commited them against the main branch,
without first
d3ck0r> updating to that branch.  At the time I wondered if monotone would
be really
d3ck0r> smart about the thing that I did, but as it turns out, the branch
tag I
d3ck0r> applied to the revision basically made no difference...
d3ck0r>
d3ck0r> This is a script which reproduces effectively what I did.  What I
would have
d3ck0r> expected in the final checkout would have been 'file' with content
'Branch1'
d3ck0r> and 'file2' with content 'branch1'.  Instead, I get 'file' with
content
d3ck0r> 'branch1 + branch2' but I did not propagate the branches... so I
would not
d3ck0r> have expected the changes to be merged...
d3ck0r>
d3ck0r> Maybe an artificial warning/error can be generated to alert the
user that
d3ck0r> such a thing will not produce what they might expect?
d3ck0r>
d3ck0r>
d3ck0r>
d3ck0r> mtn --db=test.db db init
d3ck0r> mtn --db=test.db genkey temp
d3ck0r>
d3ck0r> mtn --db=test.db --key=temp --branch=branch1 setup .
d3ck0r>
d3ck0r> echo "Branch1" >file
d3ck0r> mtn --db=test.db --key=temp  add file
d3ck0r> mtn --db=test.db --key=temp  commit -m "Begin branch1"
d3ck0r>
d3ck0r> echo "+Branch2" >>file
d3ck0r> mtn --db=test.db --key=temp --branch=branch2 commit -m "Changed
file, begin
d3ck0r> branch2"
d3ck0r>
d3ck0r> echo "branch1" >file2
d3ck0r> mtn --db=test.db --key=temp add file2
d3ck0r> mtn --db=test.db --key=temp --branch=branch1 commit -m "Add a file
to
d3ck0r> branch1"
d3ck0r>
d3ck0r> mkdir checkout
d3ck0r> cd checkout
d3ck0r> mtn --db=../test.db --key=temp --branch=branch1 co .
d3ck0r>
d3ck0r>
d3ck0r>
d3ck0r>  ---
d3ck0r>
d3ck0r>
d3ck0r>
d3ck0r> Again, I was working on 'branch', made changes I didn't want to
share with
d3ck0r> the public yet and commited changes on --branch='branch.test'.  I
then
d3ck0r> modified other code, and commited that code using
--branch='branch' to
d3ck0r> commit it against the main branch instead of branch.test.  But at
the end,
d3ck0r> the changes added to branch.test were included in 'branch'
automatically...


___
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: I think this behavior might be wrong....

[J Decker]

On 5/22/07, Nathaniel Smith <[EMAIL PROTECTED]> wrote:


On Tue, May 22, 2007 at 01:35:44AM -0700, J Decker wrote:
>It would be really nice if the current branch tag in _MTN/options
would
>update even if the revision is already up to date.

What version of mtn are you using?  I thought this bug was fixed
already...



mtn --version
monotone 0.34 (base revision: 6ae6de16b31495a773ac3002505ad51f2e4a8616)


-- Nathaniel


--
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
-- Serendipities, Umberto Eco


___
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] I think this behavior might be wrong....

[J Decker]

On 5/22/07, Brian May <[EMAIL PROTECTED]> wrote:


>>>>> "J" == J Decker  writes:

J> mtn --db=test.db db init
J> mtn --db=test.db genkey temp

J> mtn --db=test.db --key=temp --branch=branch1 setup .

J> echo "Branch1" >file
J> mtn --db=test.db --key=temp  add file
J> mtn --db=test.db --key=temp  commit -m "Begin branch1"

J> echo "+Branch2" >>file
J> mtn --db=test.db --key=temp --branch=branch2 commit -m "Changed
file, begin branch2"

Here the working directory contains the branch2 files.

J> echo "branch1" >file2
J> mtn --db=test.db --key=temp add file2
J> mtn --db=test.db --key=temp --branch=branch1 commit -m "Add a file
to branch1"




oh dang, i meant to specify file2 specifically on this commit.
turns out that that does not modify the end result, since, as someone
metioned in an earlier response, this last commit is related with an
ancestor of the last commit to branch2, not to the head of branch1.


The way I see it, this commit means everything in the working

directory will appear as a new revision in branch1. Since the working
directory is still branch2, this means everything in branch2 will be
included in this new revision.



The way I see it, if I specify '--branch=...' as part of a commit line, I
would like the diff between the head of that branch and the files specified
stored.  I would like this diff to be related with an ancestor of the head
of the branch specified.  If the branch has mutliple heads, require a merge
of those heads before allowing the commit to proceed.

If there is no branch previously existing, then yes, the branch should be
created and related with the current revision marked in the current
workspace, however, if the branch does exist, I would expect, again, the
diff of the files sepcified (all fiels in the workspace of course if none
otheriwse specified) to be commited against the head of the branch
specified.

Including, if the current branch that the workspace is currently on, is the
one that is sp[ecified, but the current revision of the workspace is not the
head revision, then the changes should be commited against the head
revision, not the current one.  If you want the changes to be commited
against the current revision in the workspace, just commit.

If I had manually updated the revision file without doing any update,
monotone would have gladly done the above behavior.


Maybe I am daft and/or misunderstood something, but I fail to see why

this is confusing.
--
Brian May < [EMAIL PROTECTED]>


___
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

[Monotone-devel] Windows version 0.36

[J Decker]

I recently updated to this.  I occasionally serve my database so i can
pull/push to my virtual machines on the same system.  The current version (
0.35 did not do this) ends up leaving the database locked after the client
connects to sync.(I cannot just use the database anymore without closing
the serving process)

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

[Monotone-devel] Re: Windows version 0.36

[J Decker]

This really IS a problem will it be sorted out?

On 8/23/07, J Decker <[EMAIL PROTECTED]> wrote:
>
> I recently updated to this.  I occasionally serve my database so i can
> pull/push to my virtual machines on the same system.  The current version (
> 0.35 did not do this) ends up leaving the database locked after the client
> connects to sync.(I cannot just use the database anymore without closing
> the serving process)
>
> Jim
>
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Windows version 0.36

[J Decker]

frigging mailing lists responding to wrong places




On 8/31/07, J Decker <[EMAIL PROTECTED]> wrote:
>
> I happen to now know a bit about what sqlite does with locking.
> If you just do
>
> prepare( "select blah from somewhere" );
> step
>
> and this does not either get unmade - err destroyed?  I forget exactly
> what the close is
>
> or if't snot at the end of the result set..
>
> followed by an insert
>
> creates an externally locked condition.
>
>
> "Clean up your freaking queries!"
>
>
>



 On 8/30/07, Derek Scherger <[EMAIL PROTECTED]> wrote:
> >
> > J Decker wrote:
> > > This is only new as of 0.36... previously any locks were unlocked...
> > > this is more like a sign that some query is left hanging instead of
> > > being completed.  It's not that I'm attempting to use it at the same
> > > time, but, again previously, I could push/pull from the database and
> > > then check out with the server process still running.  (Not that it
> > was
> > > serving anything at the same time which definately resulted in
> > > a database locked condition)
> >
> > I don't know of anything that changed regarding database locks in the
> > 0.35 - 0.36 timeframe but I haven't been following all that closely. If
> > this did work previously it might just have been luck, it's not designed
> > to as far as I know. i.e. I don't *think* there's any code that says
> > "close the database after this netsync connection is finished with it".
> >
> > I've replied to the list as well in case someone else knows differently
> > though.
> >
> > Cheers,
> > Derek
> >
> >
>
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Locked Database....

[J Decker]

Some time ago I reported that monotone server process no ends up with a lock
on the database after a client syncs

I know that if my application uses sqlite, and ends up with the database in
this sort of state, I know that the data is not nessecarily flushed to the
database, (that it it can be left in the journal so only the current
application (the one with the lock) can get the data ) leads me to my
question

  How do I know if it's safe to end the server process?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: cannot drop non-empty directory during branch update

[J Decker]

Oh - yeah then it becomes a missing directory if I take the easy way
out, and just rename the path...

On 9/18/07, J Decker <[EMAIL PROTECTED]> wrote:
> I really really don't want to delete these files, I will very soon be
> back to work in this space...
>
> On 9/18/07, J Decker <[EMAIL PROTECTED]> wrote:
> > mtn.EXE: switching to branch com.fortunet.altanik
> > mtn.EXE: warning: cannot drop non-empty directory
> > 'src/fut/flashdrive/flashdrivetester'
> > mtn.EXE: misuse: 1 workspace conflicts
> >
> >
> > this is caused by creating a project with sources and building it,
> > which created objects and sub-directories in the path; then update to
> > a revision previous to the addition of that directory
> >
> > If a thing is not empty, it issues a warning, but then fails to
> > actually update.
> >
> >
> > (screams and runs around waving hands wildly) This is about the 6th
> > time this week I've run into this as I've been bouncing between the
> > versions...
> >
> > Jim
> >
> > Let me guess, monotone was never intended to work like this, so it's a
> > non issue.
> >
>


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

[Monotone-devel] Re: cannot drop non-empty directory during branch update

[J Decker]

I really really don't want to delete these files, I will very soon be
back to work in this space...

On 9/18/07, J Decker <[EMAIL PROTECTED]> wrote:
> mtn.EXE: switching to branch com.fortunet.altanik
> mtn.EXE: warning: cannot drop non-empty directory
> 'src/fut/flashdrive/flashdrivetester'
> mtn.EXE: misuse: 1 workspace conflicts
>
>
> this is caused by creating a project with sources and building it,
> which created objects and sub-directories in the path; then update to
> a revision previous to the addition of that directory
>
> If a thing is not empty, it issues a warning, but then fails to
> actually update.
>
>
> (screams and runs around waving hands wildly) This is about the 6th
> time this week I've run into this as I've been bouncing between the
> versions...
>
> Jim
>
> Let me guess, monotone was never intended to work like this, so it's a
> non issue.
>


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

[Monotone-devel] cannot drop non-empty directory during branch update

[J Decker]

mtn.EXE: switching to branch com.fortunet.altanik
mtn.EXE: warning: cannot drop non-empty directory
'src/fut/flashdrive/flashdrivetester'
mtn.EXE: misuse: 1 workspace conflicts


this is caused by creating a project with sources and building it,
which created objects and sub-directories in the path; then update to
a revision previous to the addition of that directory

If a thing is not empty, it issues a warning, but then fails to
actually update.


(screams and runs around waving hands wildly) This is about the 6th
time this week I've run into this as I've been bouncing between the
versions...

Jim

Let me guess, monotone was never intended to work like this, so it's a
non issue.


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

Re: [Monotone-devel] Re: cannot drop non-empty directory during branch update

[J Decker]

(true story)

Okay turns out they weren't products of the build (even though no
matter what they are, if you are developing a few bits of code in many
places reversion is crazy annoying )

What if ... I start a project, add a few base things that are
definatly in, but I'm adding a module that may or may not be good... I
don't want to commit it - cause it'll never go away... I don't want to
delete it - it's got a few ideas

if the directory can't be droped it should be a warning, and the
update should continue

(okay really the true story)
in the process of this if there are other files which can be dropped
it may indeed drop those... forcing one to do a mtn revert --missing,
mtn update (again) oh - another place needs to be cleaned... (find,
delete, delete the first again, cause it will cause afailure i not
manually cleaned) , mtn revert --missing, mtn update (oop damn, again,
another project changed slighly, someone commited into a directory
called sqllib instead of SQLlib, oh and a third one? they commited
into SqlLib, and can't create the directory causeit already exitsts,
can't delete the directory cause it's not empty... okay screw this ...

mtn head,  edit _MTN/revision , edit
_MTN/options, fix branch

mtn revert .
and whoa everthing updates (except now I lose those changes in yet
other projects)


maybe noone has any projects that include 20 libraries and 8
programs... everyone writes one little application and calls it good -
like mtn - that's just one utility, which when working on certain
things requires bouncing to many other related stuff - what if I were
a boost maintainer too and found a really slick way to optimize
something...




On 9/18/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> On 9/18/07, William Uther <[EMAIL PROTECTED]> wrote:
> > I'm not sure this makes a real difference.  Either you want to re-
> > generate them or you don't.  If you don't want to re-generate them
> > then you should add them.
>
> I have nothing in particular to add to the rest of the discussion, but
> I want to point out that there are legitimate use cases for putting
> generated files into version control.  The one I know about is when
> the source changes rarely *and* you need an unusual tool to do the
> regeneration.  For example, there's this thing called AutoGen (has
> absolutely nothing in common with automake or autoconf, except that I
> believe the name was inspired by them) which is used to generate
> several files inside the GCC repository, such as the 'fixincludes'
> script.  The script doesn't change often and we don't want to make
> people have the tool.
>
> It occurs to me that Monotone could do nice things for this scenario
> with a specialized cert on the derivative file, identifying the
> source(s) by file ID and content hash.  This would have two effects:
> if the source file is being checked in and the derivative file isn't,
> the commit is rejected; and on checkout we somehow ensure that the
> last modification time of the derivative file is later than the last
> modification time of the source files.  (GCC has a horrible
> post-checkout script you're supposed to run to do this.  It would be
> *really nice* if it happened automatically.)
>
> 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

[Monotone-devel] More On existing/missing directory update failures...

[J Decker]

I'm about to go into this head long

I started gathering conifgurations, and commiting them into source
control.  I started this as an independant branch, added everything
and am about to merge_into_dir that branch into the location within
the project's branch that they should go... now while I was doing all
of this work, I put them in that location by hand, and updated the
makefile to test that they will get included for the projects
output... but I already added them into their own brahc, so I can't
(shouldn't) add them to the current branch...

But, once I do the merge_into_dir, and update, this will blow up. *sigh*

Jim


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

[Monotone-devel] Yet another instance of failure to drop non empty directory.

[J Decker]

I have this directory that has a workspace from monotone which has a
workspace from subversion checked out in the same place.  Subversion,
being not as elegant as monotone, maintains a directory in each and
every path... so as I'm going through and cleaning up junk in my
monotone repository, I can't update, cause there is a directory
include/freetype which is not empty... because it has a subversion
directory in it... which once I update would be nice to have there so
I can also do the drop from subversion...

Is this ever going to get fixed so that

mtn.EXE: selected update target c7201136f3b3ee3555941a0f10b12050566cc4fe
mtn.EXE: warning: attach node 2147487689 blocked by unversioned path
'src/tests/Makefile'
mtn.EXE: warning: attach node 2147487690 blocked by unversioned path
'src/tests/xml_sql_record.c'
mtn.EXE: warning: cannot drop non-empty directory 'include/freetype'
mtn.EXE: warning: cannot drop non-empty directory 'include/freetype/config'
mtn.EXE: warning: cannot drop non-empty directory 'include/freetype/internal'
mtn.EXE: warning: cannot drop non-empty directory
'include/freetype/internal/services'

All of these WARNINGS are just that, and do not stop the update?

Or, am I going to actually have to go fix this myself?


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

Re: [Monotone-devel] nested workspaces

[J Decker]

I found this works very well with monotone.

monotone will see the sub project in the subproject and the overall
when outside; unless you specify the root directory which many command
have the option for.
It includes by default ignoring _MTN, so adding that project you will
have to specify to ignore the ignores.

For tracking purposes, I avoided doing commits to the main project and
only commited in the subproject, and used propagate to merge the
changes to the main... then I could double check I didn't miss a
commit by doing a diff on the parent also

You can construct a main project from a sub project by using the
pivot_root feature; create a new root directory, and then pivot the
root to that, so the existing project becomes included as a directory.

NEVER propagate from the overall project to a subproject.

You can really only keep the _MTN/revision information because options
contains workspace specific information... which becomes somewhat of
an issue updating the checkout of the subprojects to get a good
options file.

I do think this confuses other programmers as noone was able to
continue without always asking how to propagate.

I thought it would be easier to have a project that maintained a
structure between the subprojects so they could have some knowledge of
each other through the master project... but it really isn't.  Each
part should build itself into a installed state, and the other
projects should target that installed information instead of direct
sources.



On Thu, Dec 5, 2013 at 2:19 PM, Hendrik Boom  wrote:
> I've never found a clear discription of what happens with nested workspaces.
> Maybe I just haven't looked enough.
>
> For example, I may have a project and a subproject.
>
> I checkout the project, and get a directory fill of stuff, including a
> _MTN directory.
>
> Subsequently cd into that and check out another project into a new
> directory I'll call subproject.  It too has a _MTN directory.
>
> How do these two interact.
>
> I presume that when I'm in the subproject directory, monotone will see
> just the subproject.
>
> But when I'm in the main  project, to what extent is monotone aware of
> the subproject?  When doing things like mtn list known, does it see
> the _MTN file of the subproject as a warning not to go there?
>
> Or can I take files that are part of the subproject and add them into
> the main project as well, so that both monotones apply updates to the
> same file?
>
> Or can I even go so far as to put the _MTN directories of the
> subproject under revision control as part of the main workspace? (I
> suspect this is a bad idea; I'm interested in just what the limits
> are).
>
> Or what?
>
> I'm thinking of using this in a context where the subprojects are
> really independent projects in their own right, but the main project
> contains their workspaces, documentation files that organize the
> collection, and other files that may or may not later become projects
> in their own right.
>
> Assuming this model is feasible, of course.
>
>  -- 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] release 1.1 - status

[J Decker]

They have more up to date windows SDK headers also.

On Mon, Feb 3, 2014 at 7:01 AM, Stephen Leake
 wrote:
> Markus Wanner  writes:
>
>> On 02/02/2014 11:17 PM, Stephen Leake wrote:
>>> Although it appears we should switch to MinGW-w64, I think that can
>>> wait for the next release.
>>
>> Does "switch" here refer to the build we provide?
>
> Yes.
>
>> Or does it imply we
>> have compilation issues, there? Did you test MinGW-64?
>
> I have not tested with MinGW-64; I have not even installed it yet. I'm
> just reporting that I've heard other projects are switching to MinGW-64,
> because it supports 64 and 32 bit Windows, while MinGW 32 only supports
> 32 bit Windows.
>
> I'll get to it sometime, but certainly not for a 1.1 release.
>
> --
> -- 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] C++11

[J Decker]

I didn't see an answer to 'would you
mind to give guys like me some examples / judgement why monotone should
switch to C++11? I could think of having less code in monotone because
more is taken care of already in the stdlib, but some examples would be
nice.'

other than c++11 being new and shiny?  I know it has builtin thread support
which might removal of some ifdefs ... but I'm sure that's an insignificant
change
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] fixing old commit messages

[J Decker]

isn't it just as simple as adding a comment?

mtn comment rev [comment]

This adds a new comment to a committed revision (see Selectors
). If comment is not
provided, it is obtained from the Lua hook edit_comment
; the hook
is passed an empty string.

This command is a synonym for mtn cert rev comment comment.

which becomes a lot easier than any other version system...


On Tue, Jun 17, 2014 at 9:05 AM, Markus Wanner  wrote:

> On 06/14/2014 06:32 PM, Hendrik Boom wrote:
> > When I commit a revision, I get to write a message explaining what this
> > revision does.
> >
> > But sometines I look at the old commit messages and cringe.
> >
> > I have troubleetyping correctly, and there are often typos and worse.
> >
> > Is there any way to edit an old commit message?
>
> What I sometimes do is commit to a private feature branch, where I don't
> have to worry much about the commit message. Then "merge" the branch
> with mtn pluck, thinking harder about the message after the entire
> feature is done (testing takes a while; usually I end up having multiple
> commits in the branch or even merges from the parent branch) and then
> suspending that feature branch.
>
> Of course, you need to plan ahead for that to work. And technically it's
> not really editing the commit message, but rather adding an intermediate
> step. But one that doesn't need to be visible to others.
>
> 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

[Monotone-devel] Boton 1.11 failure

[J Decker]

Building a new system with Arch;
unfortunatly they give sources in stupid places and have no monotone
package.
I see that Boton as stopped using Monotone as a version control...

issues; init.h isn't automatically included by boton/boton.h so the
configure script fails
pipe.h isn't automatically included so some other things fail
filter.h isn't automatically included (although this includes pipe.h)

and ui.h has disappeared and there is no User_Interface class in Botan.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] coming from monotone....

[J Decker]

what is the equivalent of mtn pivot_root in git?

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

Re: [Monotone-devel] coming from monotone....

[J Decker]

I used it to take a source tree, take a large chunk out of it, make
that the new root, move a few extra things, and delete the rest.   I
have a thing that can be more effective if chopped into individual
compoents... But, if there were changes in the main line to those
sources which I haven't really touched in a lot of years will still be
able to get the occsional update from the master.

propagate in the wrong direction is a terribly bad idea though..

but I realized you said it doesn't trace renames... only content in
git... I'm just not sure if chagnes would propagate

On Thu, Feb 18, 2016 at 1:50 AM, Brian May
 wrote:
> J Decker  writes:
>
>> what is the equivalent of mtn pivot_root in git?
>
> I don't think there is a direct equivalent, and as git doesn't keep
> track of renames or directories like monotone does, I am not sure there
> is any need for anything like this in git. Move the files where they
> need to be and don't worry about the directories.
>
> This is a very generic answer, if you gave more details as to what you
> are trying to do it is possible there is a better answer for your
> specific case.
> --
> Brian May 
>
> ___
> 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] javascript monotone

[J Decker]

I don't know how to phrase this.
This is meant for the architect of the innermost guts of monotone...
strip away a database, strip away a file system, and just track
revisions.  track merging of chains

I read somewhere that in the distribution of monotone revision chunks
that there are conglomerated chunks of revision that get sent and can
later be referenced with a key(?) Maybe that's where the failure is...
Sorry I've been imagining monotone doing a different job than source
control, like ledger transactions for bank accounts.  And to share
those.  The chains of transactions are verifiable, and I guess that's
what bitcoin is kinda built on.

I'd like a system for sharing ID's between nodes in a cluster
where IDs are added, sometimes transfer, sometimes don't, those
clusters exist as a memory idea somewhere in monotone at some point?
Even if for optimization it is cursor driven so you can only see a
portion of it at a time.

and something entirely without boost.

Can that be written and shared as a NPM module for node? :)   I hear
that v8 does extra clever things that allow it to more deeply optimize
than a static compile does... it could; but it doesn't.

- Or -
I'd like a VFS interface (virtual file system) interface to monotone
so I can load a place to store the database?  Could just use my
existing sqlite interface with a small hack I suppose... but you
probably leverage more than I do (which is almost sufficient to look
like ODBC's retarded stepcousin )

I dunno maybe it's not so hard?

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

Re: [Monotone-devel] javascript monotone

[J Decker]

I recently learned there is javascript beyond browser web page, and
that there's actually a language.  The language has some interesting
properties.  It has a default library of stuff that's fairly
functional (from a network communcations sort of perspective; could
wish they had their own websock which is a few hundred lines of code
but I digress)

What I was thinking is part distributed database.
The branches may be saved on a disk, may be temporary in memory, each
A revision id. has a history of authority in a sense... But; it may
exist as a revision packet in a branch that is on a full duplex
datagram pipe and then be removed from the system.

But distributing the appriprate revision links respinsible for that
node would be able to transfer authentication to the remote...

Monotone did do one thing very right ( keep the files as they are and
never ask if you should be one way some place or another; though maybe
a forum of scripts for user contribution 'oh ya, I *DO* want that'
which I saw at the time.  (git recemtly changed policy settings, and
the default is wrong).


But no, monotone exists as an entity tracking thing.  If I modify a
content, it may store that change in addtion to the current revision.
If this were say a shopping list, then it would be least storage?  And
I could always get a foreach() operator that's a snapshot of all... or
I could get single things in the list...



And it struck me that as a global object tracking system, could make
self-discovering-self-loading nodes with small bits of storage that is
a private db, a shared db, could be files...  (the vfs is on the side
of the sqlite side really also ... wasn't really thinking of vfs on
the front-end?  But sure, because I have this disk that I want to feed
it?

-
Douglas Crockford wrote a book 'javascript - the good parts'  he gave
a talk at many places where he covered to roots of what is good stuff.
And you can get by without ever using a single new :)  because { a:
"is object" }.

and json is really kinda slick, and as expressive as xml... and
javascript is not going away.

There is the Atom/Electorn platform that Github is producing/hosting,
electorn is chromium-content wrapped in a thin javascript loader.

There are inconsistanies when you get to the DOM layer... but did you
know Encscriptem can compile source to javascipt by bytecode?

And I think sqlite is fabulous, and probably better now than it was...
and it's sad that it was said to be slow once upon a time (some
youtube video I saw with linus torvalds speaking of other experiences
at the time)

But ... if I could

var thing = require( "mtn://org.d3x0r.sack/src/" ); might be kinda slick...
node does have addon support; but... I think a general
reimplementation of the core just for kicks might be entertaining :)


which unfortunatly is off-sight... but I dunno coordiante some pull in
the back end, which would require knowing a directory of where things
were and why you might want to know they were there?

I saw a google V8 tech presnetaiton about things they do to speed it
up... and if code executes a certain way, deep inlining can be done,
which I suppose can be done by a optimizing comipler;... but it
doesn't KNOW that 'this exception handler will never execute'  but you
can learn that.

I was on a youtube kick for a week learning the 5 hours crockford had
to teach; and it's not what you will find if you search for common
answers.

The other issue is that there's jquery that uses a magic variable $
everywhere, and they mean things with it.. another uses _ as a
variable so _.thing is what you want to get

BUT you don't have to live in that world... node itself is a simple
binary to grab and tinker with, electron has a little complex startup
but it's managable...

(sorry for all the bad spellings)


On Tue, Mar 1, 2016 at 3:20 PM, Hendrik Boom  wrote:
> On Tue, Mar 01, 2016 at 07:27:51PM +0100, Markus Wanner wrote:
>>
>> (I personally find it hard to believe that JIT can generally be faster
>> than ahead of time compilation, but...)
>
> It can be faster if you only want to run a small part of the program.
>
> It can be faster if the intermediate code is so compact that compiling
> it to machine code saves disk reading time.
>
> It can be faster if at run time you discover what types are really used
> in an otherwise statically untyped program.
>
> But I can't see it being much faster for the kinds of languages I prefer
> to use.
>
> -- 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

[Monotone-devel] build failure

[J Decker]

Arch Linux has no package for monotone.
it installs a Botan-1.11(?) as 'Botan'

I tried to link; but it doesn't compele for a variety of c++14
errors... in configure

checking for botan using botan-1.11.pc... yes
checking whether botan is usable... no
configure: *** botan_CFLAGS=-I/usr/include/botan-1.11
configure: *** botan_LIBS=-lbotan-1.11
configure: error: in `/home/d3x0r/addons/srcpit/monotone-1.1':
configure: error: Must be able to compile and link programs against botan.

| /usr/lib/pkgconfig/botan-1.11.pc
configure:5066: checking for botan using botan-1.11.pc
configure:5075: $PKG_CONFIG --exists --print-errors "$c$_verreq"
configure:5078: $? = 0
configure:5093: $PKG_CONFIG --exists --print-errors "$c$_verreq"
configure:5096: $? = 0
configure:5109: result: yes
configure:5182: checking whether botan is usable
configure:5206: g++ -o conftest -g -O2 -Wall -W -Wno-unused
-I/usr/include/botan-1.11  conftest.cpp -lz  -lbotan-1.11 >&5
In file included from /usr/include/c++/5.3.0/cstdint:35:0,
 from /usr/include/botan-1.11/botan/types.h:15,
 from /usr/include/botan-1.11/botan/scan_name.h:11,
 from /usr/include/botan-1.11/botan/block_cipher.h:11,
 from /usr/include/botan-1.11/botan/lookup.h:11,
 from /usr/include/botan-1.11/botan/botan.h:11,
 from conftest.cpp:14:
/usr/include/c++/5.3.0/bits/c++0x_warning.h:32:2: error: #error This
file requires compiler and library support for the ISO C++ 2011
standard. This support must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
 #error This file requires compiler and library support \
  ^
In file included from /usr/include/botan-1.11/botan/sym_algo.h:12:0,
 from /usr/include/botan-1.11/botan/block_cipher.h:12,
 from /usr/include/botan-1.11/botan/lookup.h:11,
 from /usr/include/botan-1.11/botan/botan.h:11,
 from conftest.cpp:14:
/usr/include/botan-1.11/botan/exceptn.h:27:7: warning: identifier
'noexcept' is a keyword in C++11 [-Wc++0x-compat]
   const char* what() const BOTAN_NOEXCEPT override { return
m_what.c_str(); }
   ^
In file included from /usr/include/botan-1.11/botan/secmem.h:17:0,
 from /usr/include/botan-1.11/botan/symkey.h:11,

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

Re: [Monotone-devel] build failure

[J Decker]

[root@tower2 firewall]# pacman -Sq monotone
error: target not found: monotone
[root@tower2 firewall]# pacman -Syu monotone
:: Synchronizing package databases...
 core121.7 KiB   231K/s 00:01
[] 100%
 extra  1768.1 KiB   346K/s 00:05
[] 100%
 community 3.4 MiB   332K/s 00:10
[] 100%
error: target not found: monotone

[root@tower2 monotone]# pacman -Sq botan-stable
error: target not found: botan-stable

I have no yaourt

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

after git clone of botan stable
makepkg -s
..

==> Verifying source file signatures with gpg...
Botan-1.10.12.tgz ... FAILED (the public key
621DAF6411E1851C4CF9A2E16211EBF1EFBADFBC is not trusted)
==> ERROR: One or more PGP signatures could not be verified!

-
finally found yaourt

[d3x0r@tower2 yaourt]$ makepkg -sri
==> Making package: yaourt 1.8-1 (Thu Mar  3 13:27:01 PST 2016)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: package-query>=1.8
==> ERROR: 'pacman' failed to install missing dependencies.


found your last message from 9/5/15 (sorry it was 6 months ago so I
forgot I noted this before)
tried that gpg recv-key too... but no help

On Thu, Mar 3, 2016 at 10:42 AM, archaurwiki  wrote:
> Arch Linux *does* have a package for monotone:
>
> https://aur4.archlinux.org/packages/monotone/
>
> It builds against botan stable.
>
> Simply issue:
>
> yaourt -Syua monotone
>
> or
>
> git clone https://aur.archlinux.org/monotone.git
> cd monotone && makepkg -s
>
>
> J Decker:
>> Arch Linux has no package for monotone.
>> it installs a Botan-1.11(?) as 'Botan'
>>
>> I tried to link; but it doesn't compele for a variety of c++14
>> errors... in configure
>>
>> checking for botan using botan-1.11.pc... yes
>> checking whether botan is usable... no
>> configure: *** botan_CFLAGS=-I/usr/include/botan-1.11
>> configure: *** botan_LIBS=-lbotan-1.11
>> configure: error: in `/home/d3x0r/addons/srcpit/monotone-1.1':
>> configure: error: Must be able to compile and link programs against botan.
>>
>> | /usr/lib/pkgconfig/botan-1.11.pc
>> configure:5066: checking for botan using botan-1.11.pc
>> configure:5075: $PKG_CONFIG --exists --print-errors "$c$_verreq"
>> configure:5078: $? = 0
>> configure:5093: $PKG_CONFIG --exists --print-errors "$c$_verreq"
>> configure:5096: $? = 0
>> configure:5109: result: yes
>> configure:5182: checking whether botan is usable
>> configure:5206: g++ -o conftest -g -O2 -Wall -W -Wno-unused
>> -I/usr/include/botan-1.11  conftest.cpp -lz  -lbotan-1.11 >&5
>> In file included from /usr/include/c++/5.3.0/cstdint:35:0,
>>  from /usr/include/botan-1.11/botan/types.h:15,
>>  from /usr/include/botan-1.11/botan/scan_name.h:11,
>>  from /usr/include/botan-1.11/botan/block_cipher.h:11,
>>  from /usr/include/botan-1.11/botan/lookup.h:11,
>>  from /usr/include/botan-1.11/botan/botan.h:11,
>>  from conftest.cpp:14:
>> /usr/include/c++/5.3.0/bits/c++0x_warning.h:32:2: error: #error This
>> file requires compiler and library support for the ISO C++ 2011
>> standard. This support must be enabled with the -std=c++11 or
>> -std=gnu++11 compiler options.
>>  #error This file requires compiler and library support \
>>   ^
>> In file included from /usr/include/botan-1.11/botan/sym_algo.h:12:0,
>>  from /usr/include/botan-1.11/botan/block_cipher.h:12,
>>  from /usr/include/botan-1.11/botan/lookup.h:11,
>>  from /usr/include/botan-1.11/botan/botan.h:11,
>>  from conftest.cpp:14:
>> /usr/include/botan-1.11/botan/exceptn.h:27:7: warning: identifier
>> 'noexcept' is a keyword in C++11 [-Wc++0x-compat]
>>const char* what() const BOTAN_NOEXCEPT override { return
>> m_what.c_str(); }
>>^
>> In file included from /usr/include/botan-1.11/botan/secmem.h:17:0,
>>  from /usr/include/botan-1.11/botan/symkey.h:11,
>>
>> ___
>> 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] serialization format

[J Decker]

If the structures might mutate with time something like json is pretty brief.
if you have high reliability, sqlite for instance will store a blob
with only \0 for the 0  and \\ for \ ...

which results in a copy or shift of data but only a simple comparison
if '\\'   kinda like base 254 sorta :)
depending on what character happens least you could replace  for
 or something ...



On Tue, Apr 5, 2016 at 9:25 AM, Markus Wanner  wrote:
> On 04/04/2016 10:02 PM, Ludovic Brenta wrote:
>> No but they might care about performance.  How much of monotone's time
>> is actually spent translating between binary and hex?  Is this really a
>> major performance bottleneck?
>
> Well, not the conversion between hex and binary itself, no. But the
> effect the serialization format has on hashing.
>
> Let's have a look at some perf samples gathered during a functional test
> run:
>
>> #
>> # Overhead  Shared Object  Symbol
>> #   .  
>> ...
>> #
>>  6.80%  libbotan-1.10.so.1.10  [.] 
>> _ZN5Botan12SHA_160_SSE210compress_nEPKhm
>>  3.74%  libc-2.21.so   [.] _int_free
>>  2.60%  libstdc++.so.6.0.21[.] 
>> _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base
>>  2.24%  libstdc++.so.6.0.21[.] 
>> _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
>>  1.85%  libc-2.21.so   [.] malloc
>>  1.85%  mtn[.] 
>> _ZNSt8_Rb_treeIN6option6optionI7optionsEES3_St9_IdentityIS3_ESt4lessIS3_ESaIS3_EE7_M_copyINS9_20_Reuse_or_alloc
>>  1.73%  mtn[.] 
>> _ZSt11__set_unionISt23_Rb_tree_const_iteratorIN6option6optionI7optionsEEES5_St15insert_iteratorISt3setIS4_St4le
>>  1.66%  ld-2.21.so [.] do_lookup_x
>>  1.57%  libcrypto.so.1.0.0 [.] DES_encrypt2
>>  1.36%  libc-2.21.so   [.] __memcmp_sse4_1
>>  1.17%  mtn[.] 
>> _ZNSt8_Rb_treeIN6option6optionI7optionsEES3_St9_IdentityIS3_ESt4lessIS3_ESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS
>>  1.04%  libc-2.21.so   [.] free
>>  1.03%  libc-2.21.so   [.] malloc_consolidate
>>  0.98%  [unknown]  [k] 0x817f4ca0
>>  0.75%  mtn[.] 
>> _ZNSt17_Function_handlerIFvP7optionsNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcMS0_FvS7_EE10_M_manage
>>  0.71%  ld-2.21.so [.] _dl_lookup_symbol_x
>>  0.71%  mtn[.] 
>> _ZNSt17_Function_handlerIFvP7optionsEMS0_FvvEE10_M_managerERSt9_Any_dataRKS6_St18_Manager_operation
>>  0.67%  libcrypto.so.1.0.0 [.] DES_encrypt1
>>  0.64%  libbotan-1.10.so.1.10  [.] 
>> _ZN5Botan16MDx_HashFunction12final_resultEPh
>>  0.64%  libgmp.so.10.2.0   [.] __gmpn_redc_1
>>  0.62%  [unknown]  [k] 0x811b24fa
>>  0.58%  libc-2.21.so   [.] strlen
>>  0.58%  libbotan-1.10.so.1.10  [.] 
>> _ZN5Botan16MDx_HashFunction8add_dataEPKhm
>>  0.57%  [unknown]  [k] 0x813d3417
> ...
>>  0.06%  libbotan-1.10.so.1.10  [.] _ZN5Botan10hex_decodeEPhPKcmRmb
> ...
>>  0.02%  libbotan-1.10.so.1.10  [.] _ZN5Botan10hex_encodeEPcPKhmb
>
>
> Hashing probably is the single most time consuming operation here, with
> about 8% of the time spent (note that the add_data and final_result
> methods are within the top 25 as well).
>
> The CPU time that's used for the actual hex encoding and decoding is
> vanishingly small, below 0.1%.
>
>
> Now, I'm clearly not into micro optimizations (but rather consider
> modifications like using base58 instead of the hex encoding for hashes
> presented to the user - an encoding that's certain to consume more CPU
> time, not sure how much more, though.)
>
> However, reducing the amount of data to be hashed, cached and moved
> around (in memory, network, etc..) sounds like a generally good idea to
> me (performance wise). However, it's equally clearly a bad idea from a
> usability perspective. So there's a balance. That's why I started this
> thread.
>
> Given the arguments so far I tend towards a binary encoding, as I think
> developers should be able to handle binary data. And if users really
> don't care...
>
> 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] serialization format

[J Decker]

Sorry just a sidenote;
err...
encode into utf8 codepoints maybe?  which would expand 0x80-0xFF by 1
character each... and you could violate utf rules and encode a F880
that's a 0 codepoint...

(take a value, that's a codepoint, make a utf8 version of that
value... which for 0x0 to 0x7F is that character... but it provides a
way to escape \0 if that's a concern and why are you encoding it at
all?)

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

[Monotone-devel] An abuse of pivot root

[J Decker]

Making an installer :)

I can build in-tree, commit the built image, pivot root to the image
root and use that to track distributions, and allow just commit and
propagate to update?

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

[Monotone-devel] Failed to add path with wide character

[J Decker]

This fails under windows.

I have this project which uses the directory Λ  (Greek Lamba)

"mkdir Λ"
mtn add Λ


mtn.EXE: error: could not open directory 'dekcore/?': The filename,
directory name, or volume label syntax is incorrect.

1) the input from command line to main( int argc, char **argv ) gets a '?'
2) using GetCommandLine() returns command line with '?' in it.
3) using GetCOmmandLineW() returns with correct character in it, but
it's wchar_t*

In my own project today (after discovering this, and trying to locate
where the failure is)  I now do GetCommandLineW() convert it to utf-8,
parse it using windows command line rules (quoted things stay
together, otherwise break on spaces)  and then use it normally
internally until I get to the file system again, which I do convert
the utf-8 string to wchar_t ( which is probably UCS2 and not UTF16)
and then pass the filename to wfopen()... ( CreateFileW() if
appropriate ).




C:\>mtn genkey Λ@Λ.com
mtn.EXE: misuse: bad character '?' in key name '?@?.com'

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

Re: [Monotone-devel] Failed to add path with wide character

[J Decker]

int ConvertToUTF16( wchar_t *output, TEXTRUNE rune )
https://github.com/d3x0r/SACK/blob/master/src/typelib/text.c#L2735

int ConvertToUTF8( char *output, TEXTRUNE rune )
https://github.com/d3x0r/SACK/blob/master/src/typelib/text.c#L2760

/* CTEXTSTR is LPTSTR, that is with _UNICODE it's wchar_t without it's char */
TEXTRUNE GetUtfChar( CTEXTSTR *from )
https://github.com/d3x0r/SACK/blob/master/src/typelib/text.c#L3094


*shrug*

I know there's a 'unicode' library but it's truly large.. and
certainly wcstombs/mbstowcs are useless in this regard... they do add
up to a couple hundred lines of code

http://utf8everywhere.org/

binary equivalence is sufficient; I know that tecnically canonical
conversions (changing characters to other characters that are really
the same shape) apply... but I know that sqlite takes what you give it
and doesn't care, and I know that sockets take and send stuff and
don't care... so I don't really know what sorts of applications I
would even remotely touch that did canonical replacements that destroy
binary equivalence.

On Thu, Apr 21, 2016 at 2:13 AM, Markus Wanner  wrote:
> On 04/21/2016 01:20 AM, J Decker wrote:
>> This fails under windows.
>>
>> I have this project which uses the directory Λ  (Greek Lamba)
>>
>> "mkdir Λ"
>> mtn add Λ
>
> Thanks for your report. I vaguely remember that monotone has encoding
> issues on Windows.
>
> I also noticed that the recently added colorization feature breaks
> things on (non-cygwin-)Windows, so I guess I'll have to look at that OS
> rather sooner than later.
>
> 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

[Monotone-devel] node blocked by blocked parent

[J Decker]

doing a 'mtn update'

I now get

mtn.EXE: warning: attach node 2147484550 blocked by blocked parent
'Voxelarium.2/src/voxels'
mtn.EXE: warning: attach node 2147484551 blocked by blocked parent
'Voxelarium.2/src/voxels'
mtn.EXE: warning: attach node 2147484552 blocked by blocked parent
'Voxelarium.2/src/voxels'

for a few thousand files; that's one thing I did always dislike...

why not an option 'merge into existing' or 'do nothing if already the same'

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

[Monotone-devel] Fwd: node blocked by blocked parent

[J Decker]

On Wed, Jun 1, 2016 at 12:05 AM, Markus Wanner  wrote:
> On 06/01/2016 02:45 AM, J Decker wrote:
>> mtn.EXE: warning: attach node 2147484550 blocked by blocked parent
>> 'Voxelarium.2/src/voxels'
>> mtn.EXE: warning: attach node 2147484551 blocked by blocked parent
>> 'Voxelarium.2/src/voxels'
>> mtn.EXE: warning: attach node 2147484552 blocked by blocked parent
>> 'Voxelarium.2/src/voxels'
>

> Well, what's blocking the parent? These are just subsequent errors
> (which the UI could and probably should better collect and combine into
> one, but...)
>

I have a repository that is tracked in git and in monotone.  I was
updating monotone and added two trees; three.js(187 files) and some
data in src/voxels/VOxelInfo_[1-250].txt  (okay it's only 437 some
files not thousands)

all the conflicts are exactly the same; directories are directories,
files are files, and the content of files is the same.

The easier solution was to do mtn heads, take the current revision,
stuff it in _mtn/revision as old revision and mtn revert --missing
into it; then subsequent reverts for those things which updated; some
things had changes in progress; but all of THOSE things already
existed in the repository.  (not so easy really)


So to reiterate...
start a repo in monotone
start same repo in something else (mercurial/git/...)
add same files files to both
update on another computer/directory from other repo
update on another computer/directory from monotone



>> why not an option 'merge into existing' or 'do nothing if already the same'
>
> We had discussions about merging nodes or "stitching". But merge
> semantics for things like that are far from trivial...
>
> I agree this is not an optimal solution.
>
> Kind Regards
>
> Markus Wanner
>
>

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

[Monotone-devel] Fwd: [botan-devel] Botan 2.2.0 released

[J Decker]

Not that it matters... there's still unicode filename issues.  But maybe
now you can fix botan compatibility so monotone can build on modern systems.

-- Forwarded message --
From: Jack Lloyd 
Date: Mon, Aug 7, 2017 at 1:55 PM
Subject: [botan-devel] Botan 2.2.0 released
To: botan announce list 
Cc: botan dev list 


Hello,

Botan 2.2.0 has been released with a number of new changes including:

- Ed25519 signatures
- SM2 signature and encryption schemes
- SM3 hash function
- SM4 block cipher
- Streebog hash
- PGP-S2K key derivation
- NIST SP 800-56A KDF
- Support for Intel and ARM SHA-1 and SHA-2 instructions
- HOTP and TOTP one time password algorithms
- Initial BearSSL provider
- Many additions to the FFI (C89) interface
- Dozens of smaller features and bug fixes documented in the release notes

Thanks go out to the 20 (!) individuals who contributed to this release. A
special thanks also to Ribose Inc for sponsoring several of the new
features in
this release, including the Ed25519 code, Streebog, SM algorithms, and the
greatly expanded C interface.

https://botan.randombit.net/releases/Botan-2.2.0.tgz
https://botan.randombit.net/releases/Botan-2.2.0.tgz.asc
SHA-256 c794db2ec46f6ff88f37ae76825f0c258f07880b865b6707b26acfcc4567b824

Don't forget to like us on facebook^W^W^W^Wstar us on github.

Jack
___
botan-devel mailing list
botan-de...@randombit.net
http://lists.randombit.net/mailman/listinfo/botan-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Monotone on Github?

[J Decker]

Just a reminder; it is possible to do a shallow checkout from git and only
get the last layer...
Probably no help.
git clone --depth=1

On Wed, Apr 11, 2018 at 10:19 PM, grarpamp  wrote:

> Maybe that calls for iterative local checkout, generating
> diffs, checking those into github. Haven't looked into it,
> just didn't see much that looked officialish / current on
> github for whoever / whatever might come along.
>
> ___
> 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] undoing commits

[J Decker]

I'm sure it's way late now... but isn't ist just `mtn revert` ?

On Mon, Aug 5, 2019 at 3:48 AM Ludovic Brenta 
wrote:

> Le 2019-08-05 02:21, Hendrik Boom a écrit :
> > But if were to remove the branch certs (using the first instruction),
> > is there also a way to install branch certs for the new branch?
>
> mtn approve rev [--branch=branchname] [--[no-]update]
>
>  This command puts rev on the branch branchname (defaults to the
> workspace branch).
>
>  This command is a synonym for mtn cert rev branch branchname.
>
> --
> Ludovic Brenta.
>
> ___
> 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