Re: [Monotone-devel] Re: Google Summer of Code 2006
Bruce Stephens wrote: Eclipse/netbeans/Emacs support (improving emacs support). Adding support in Trac, or creating something similar. Eclipse support is the main blocker to me suggesting a switch from CVS at my day job. An alternative to Eclipse support might be porting the git-CVS-server which Nathaniel mentioned a while ago to monotone, making it possible to use Eclipse's (and everything else's) CVS support for the time being. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Hi Nathaniel, Adding stuff to automate is easy, knowing what to add is hard. What I always say is, send details on what exactly you want to accomplish to the list, and we'll figure out what needs to be added to automate to make it work :-). -- Nathaniel I think, for a very basic GUI-based workflow the following commands are *necessary* http://dict.leo.org/ende?lp=endep=/gQPU.search=necessary: add, drop, rm, update, checkout, heads, privkey, pubkey, read, dorpkey, genkey and some funky stuff to create a database. I hope I'm not to rude :) This commands should be usefull for everybody who want's some GUI or integration in an IDE or editor. Best Regards, Ingo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Google Summer of Code 2006
Nathaniel Smith [EMAIL PROTECTED] writes: [...] I've been wondering vaguely whether there would be some way to make this work, and maybe also provide a smoother ramp-up to people just starting to use monotone. There's more overhead in starting up with monotone than other systems, because you have to make a branch name and everything (and maybe this will even get worse when we add policy branches). There's a real payoff for this, but you pay the cost up front and get the benefits later. Maybe it would be better to have some sort of anonymous branches mode that acted more like other systems's location-based branches, that one could start out with, and promote to the real branch model later? And say that you can do quilt-y stuff with anonymous branches only, so as to have a clear demarcation between revisions that can change and revisions that can't? Maybe. I'm not so sure that inventing branch names is such a pain---it's more that you know they're always going to be visible. So maybe hidden branches come in here, along with (presumably) the policy stuff, which I guess could say that some branch names should be hidden, and maybe suggest some kind of rule for new temporary ones? So if I'm working on net.venge.monotone, maybe it should be easy for me to say I want to commit some new revision to do with commands.cc splitting, and the policy covering net.venge.monotone can come up with some kind of branch name suitable for that, which would normally be hidden to other people? That might help with reviewing, and quite probably other kinds of workflow. If I can easily commit to branches that don't get in anyone's way, then they become attractive for smaller bits of work, and I can point people at them for review. Hard to know whether there's a suitable coding project there, though. I have a suspicion that someone might look at the issues for a month and decide that a suitable technical solution is monotone diff ++; monotone revert ., together with emailing diffs for review. Probably that isn't the kind of work Google is looking for. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher difficulties
In message [EMAIL PROTECTED] on Mon, 10 Apr 2006 16:09:52 +0200 (CEST), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard In message [EMAIL PROTECTED] on Mon, 10 Apr 2006 09:48:49 -0400, Ethan Blanton [EMAIL PROTECTED] said: richard richard eblanton Second, with both the usher from 0.26-pre3 and the richard eblanton usher from 0.26 as released, I am having trouble richard eblanton serving some databases which worked in 0.26-pre2. richard eblanton I am serving three databases from three 'local' richard eblanton stanzas (net.elitists.elb.configs.*, richard eblanton edu.purdue.cs.gsb.guide.*, and richard eblanton net.elitists.ical.*), and when I try to connect to richard eblanton net.elitists.elb.configs.fvwm, usher spawns a richard eblanton server for net.elitists.ical.* and connects my pull richard eblanton to that server -- needless to say, this doesn't richard eblanton work. A copy of my usher server file is likewise richard eblanton attached. richard richard Aha, yeah, the trouble is that usher was originally built to richard handle the distinction between different sub-servers by richard hostname only, and you use the same hostname for all of them. richard I did make a change so it would accept several stanzas with richard the same hostname, but it seems I didn't look closely enough richard at the the rest of the code, so you're currently stuck with richard having to separate the sub-servers at a hostname level. richard richard I have the same goal as you, to have sub-servers richard differentiated by branch patterns as well as hostnames, so richard I'll take a closer look in a few days and see what can be richard done with it. I've been experimenting and thinking, and figured that I hadn't entirely understood how usher was meant to work. Basically, what I said is still how it is, for entries that have a hostname, they will be selected by hostname only. However, IF there is no entry with a matching hostname, usher will also check for a matching pattern. And this is actually the way it should be, usher is primarly built to provide so called virtual hosting, and only uses virtual patterns as a fallback. I've made a few changes in usher.cc, so it will tell you a bit better what happens, and I think that will be the extent of what I do with it. BTW, the fix I provided earlier wasn't at all about being able to have several entries with the same hostname, it was about avoiding segfaults when usher removed hosts or patterns from earlier entries when a new one with the same hostname of pattern was loaded. 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
Re: [Monotone-devel] Google Summer of Code 2006
Have we thought about projects related to quality, e.g., performance regression test framework and tests; documentation; multi-server testing; website enhancements; monotone public hosting; etc.? Adding projects like this may enable people who are interested in Monotone but do not have the requisite hacking skills to get involved and contribute in valuable ways. Richard ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Richard Li schrieb: Have we thought about projects related to quality, e.g., performance regression test framework and tests; documentation; multi-server testing; website enhancements; monotone public hosting; etc.? Indeed, all good points here - I already mentioned earlier that there are many many helpful tools and ressources available for mtn, but all these things are poorly integrated in the main website. Btw... what do you mean with public hosting? Tommy. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Google Summer of Code 2006
Richard Li [EMAIL PROTECTED] writes: Have we thought about projects related to quality, e.g., performance regression test framework and tests; documentation; multi-server testing; website enhancements; monotone public hosting; etc.? Adding projects like this may enable people who are interested in Monotone but do not have the requisite hacking skills to get involved and contribute in valuable ways. I think SoC is about developing. They specifically exclude documentation-only projects, for example, http://code.google.com/soc/studentfaq.html#27. I'd guess that would include improvements to the monotone website. The other things you suggest seem like they'd probably include the relevant quantity of hacking, though. But yeah, it does seem to exclude contributions that most projects would regard as valuable. Google's paying, though, so I guess they set the rules. (Some GNU/Linux distribution company could offer rewards under different rules, if they wanted.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Btw... what do you mean with public hosting? Sourceforge offers CVS hosting; gna.org offers Arch, Subversion, and CVS hosting. So enabling one of these sites to offer Monotone hosting. I would imagine that the process of setting this up could drive some feature development in Monotone as well. Richard ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Richard Li [EMAIL PROTECTED] wrote: Sourceforge offers CVS hosting; gna.org offers Arch, Subversion, and CVS hosting. So enabling one of these sites to offer Monotone hosting. I would imagine that the process of setting this up could drive some feature development in Monotone as well. There's been a lot of talk lately on the [EMAIL PROTECTED] list about this. Currently, Savannah offers CVS and GNU Arch, but obviously people want to run their favorite SCM's to work on their projects. Subversion has come up in the discussion (with some loud approval), and I dropped the Monotone with usher suggestion into the fray. It was rejected on the issue of security, that if usher were allowed to launch 'mtn serve' instances, they would be required to share the same system user/group permissions. A single compromised usher instance would then give unmitigated access to each of the services it started. The alternative I proposed was to manage the 'mtn serve' instances separately, then use usher to proxy. Some of what needs to be done in order to pull this off is to have management scripts for hosting monotone servers in place. I asked Greydon if inetd-enabling monotone would work, but he indicated that there would be database locking issues. I've added a feature-request to daemonize monotone [1], which would certainly help with launching and controlling 'mtn serve' instances. There is the possibility of adding setuid/setgid calls to usher, but that means usher would need to be run as root or have some sort of capabilities package enabled in the kernel to assign these rights to an unprivileged user. A little scary, if you ask me, since usher is processing public requests. There's the Postfix way of launching new services, a master server. usher could make requests of the master server to launch a new 'mtn serve' instance as a given user. i.e. The 'gnats' user to launch 'mtn serve' on the GNATS project's gnats.mtn database. IMHO, working with the Savannah team to serve Monotone would be quite awesome. ;-) A good Google SoC project. References == 1. https://savannah.nongnu.org/bugs/?func=detailitemitem_id=16177 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
In message [EMAIL PROTECTED] on Fri, 21 Apr 2006 09:54:17 -0500, Chad Walstrom [EMAIL PROTECTED] said: chewie There is the possibility of adding setuid/setgid calls to usher, but chewie that means usher would need to be run as root or have some sort of chewie capabilities package enabled in the kernel to assign these rights to chewie an unprivileged user. A little scary, if you ask me, since usher is chewie processing public requests. chewie chewie There's the Postfix way of launching new services, a master server. chewie usher could make requests of the master server to launch a new 'mtn chewie serve' instance as a given user. i.e. The 'gnats' user to launch 'mtn chewie serve' on the GNATS project's gnats.mtn database. I'm sorry, why can't usher *be* the master server? Adding a master server in between would just add a layer of complexity that gives nothing extra in return. 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
Re: [Monotone-devel] Google Summer of Code 2006
Richard Levitte - VMS Whacker spake unto us the following wisdom: In message [EMAIL PROTECTED] on Fri, 21 Apr 2006 09:54:17 -0500, Chad Walstrom [EMAIL PROTECTED] said: There's the Postfix way of launching new services, a master server. usher could make requests of the master server to launch a new 'mtn serve' instance as a given user. i.e. The 'gnats' user to launch 'mtn serve' on the GNATS project's gnats.mtn database. I'm sorry, why can't usher *be* the master server? Adding a master server in between would just add a layer of complexity that gives nothing extra in return. I for one would much rather the listening daemon didn't have to run with root privileges, such that it could execute servers as other users... Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
In message [EMAIL PROTECTED] on Fri, 21 Apr 2006 11:29:00 -0400, Ethan Blanton [EMAIL PROTECTED] said: eblanton Richard Levitte - VMS Whacker spake unto us the following wisdom: eblanton I'm sorry, why can't usher *be* the master server? Adding eblanton a master server in between would just add a layer of eblanton complexity that gives nothing extra in return. eblanton eblanton I for one would much rather the listening daemon didn't have eblanton to run with root privileges, such that it could execute eblanton servers as other users... So your listening server would basically be a proxy that sends bit back and forth between a remote client and a local master server process. In what way does that give you extra security? I trust you don't run sshd, apache or any other server that requires authentication and authorisation or is capable thereof, btw :-). 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
Re: [Monotone-devel] Google Summer of Code 2006
Richard Levitte - VMS Whacker spake unto us the following wisdom:
In message [EMAIL PROTECTED] on Fri, 21 Apr 2006 11:29:00 -0400, Ethan
Blanton [EMAIL PROTECTED] said:
eblanton Richard Levitte - VMS Whacker spake unto us the following wisdom:
eblanton I'm sorry, why can't usher *be* the master server? Adding
eblanton a master server in between would just add a layer of
eblanton complexity that gives nothing extra in return.
eblanton
eblanton I for one would much rather the listening daemon didn't have
eblanton to run with root privileges, such that it could execute
eblanton servers as other users...
So your listening server would basically be a proxy that sends bit
back and forth between a remote client and a local master server
process. In what way does that give you extra security?
No, not at all like that. I would rather, as the previous poster
suggested, usher received the incoming data, and rather than spawning
the monotone server directly (as it does now), it requested a
privileged process to spawn the monotone server on its behalf and then
communicated with that server.
The extra security comes in in that the usher server which listens to
the outside world and the privileged server cooperate in a very simple
and well-defined manner (e.g., perhaps the listening server sends
simply a tuple of {hostname, collection} to the privileged server, and
receives a port number in return). I believe netsync cannot be
considered a simple and well-defined manner.
I trust you don't run sshd, apache or any other server that requires
authentication and authorisation or is capable thereof, btw :-).
For one, sshd and apache have a *lot* more eyeballs looking at them
than monotone does. For another, most of these types of services use
a very similar plan to what I just outlined -- perhaps you remember
the sshd privsep push a few years back? What about, for example,
courier using a dedicated process for authentication? I don't know
about you, but my apache processes which serve pages run as www-data,
not root.
In the very example the previous poster mentioned, postfix has a
master process which runs as root and spawns child processes with
the appropriate user ID and privelege level -- for example, opening
the (privileged) port 25 and then handing the handling of that port
off to a process named smtpd which runs as the postfix user.
There is no need to introduce a *new* system which shares the same
fundamental security flaws we have learned to correct in old systems.
Ethan
--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, On Crimes and Punishments, 1764
signature.asc
Description: Digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
In message [EMAIL PROTECTED] on Fri, 21 Apr 2006 13:29:36 -0400, Ethan Blanton [EMAIL PROTECTED] said: eblanton Richard Levitte - VMS Whacker spake unto us the following wisdom: eblanton So your listening server would basically be a proxy that eblanton sends bit back and forth between a remote client and a eblanton local master server process. In what way does that give eblanton you extra security? eblanton eblanton No, not at all like that. I would rather, as the previous eblanton poster suggested, usher received the incoming data, and eblanton rather than spawning the monotone server directly (as it eblanton does now), it requested a privileged process to spawn the eblanton monotone server on its behalf and then communicated with eblanton that server. Ah, I missed that other post. That makes a lot more sense. 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
Re: [Monotone-devel] Google Summer of Code 2006
On Fri, 2006-04-21 at 13:29 -0400, Ethan Blanton wrote:
The extra security comes in in that the usher server which listens to
the outside world and the privileged server cooperate in a very simple
and well-defined manner (e.g., perhaps the listening server sends
simply a tuple of {hostname, collection} to the privileged server, and
receives a port number in return). I believe netsync cannot be
considered a simple and well-defined manner.
It doesn't actually parse the netsync stream; it considers it an opaque
bytestream and just forwards it to the monotone server.
What it does understand is that the stream starts with a sequence of
[byte] [byte] [size] [size] [host] [size] [pattern]
, which is the only thing it looks at. This is a simple {hostname,
collection} tuple, just with 2 opaque bytes in front of it. (The only
slight complexity is that the sizes are in uleb128 format, instead of
fixed-size integers.)
Really, I'd be more worried about how it handles the server list (since
that code has had crashes in it), which has to be on the secure side.
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Thank you, Ethan, for replying. We are seeing eye to eye on this one. OpenSSH has had nothing but problems with trying to debug and secure the privileged separation code. It has poor interaction with other authentication systems, and has been all-around buggy. Yet, like Ethan stated, there are more eyes, and the CAN bulletins are generally made AFTER a fix had been published: they're that fast. ;-) Like Ethan, I also run my web server as an unprivileged user and don't allow suexec. Richard is right in that having a master process that runs as root to which usher talks adds complexity (but not much). It also insulates the public interface from risky tasks, such as switching process users. Of course, you wouldn't need the master process if: 1. You never host local databases 2. You're OK with usher running multiple databases as a single user. 3. You manage (launch) the servers with some other system/setup If you need the extra security of running servers as different users (Savannah), then another management solution is necessary. Running thousands of servers all the time. (Ouch) Implement some sort of firewall port-knocking swatch launcher. (Icky. Yes, I said, Icky.) The nice thing about having a master process is that it doesn't have to be that complex. Listen to a socket. Receive a request from usher for a local database. Launch 'mtn -d DBPATH serve --bind 127.0.0.1 --port RANDPORT ...' as the appropriate user. Give usher the port or failure message. usher than works as it normally does. It just needs a new target, a socket to the master process. Anyway, it's a brain-storming feature request. Not a high priority, but if we want Monotone on Savannah, I'd hedge my bets that it would be well-received by the Savannah admins. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] db check after upgrade fails
Hi. I just upgraded from monotone 0.25-2 to 0.26, following the instructions in the UPGRADE file. I used to have the .deb monotone 0.25-2 file on a sid box, and installed the .deb for 0.26. First I did: $ mtn db rosterify --db main.db mtn: calculating necessary migration steps mtn: migrating data mtn: committing changes to database $ mtn db rosterify -k my_new_key --db main.db mtn: converting existing revision graph to new roster-style revisions mtn: certs in | certs out | nodes | revs out mtn:2,744 | 0 | 737 |0 mtn: scanning for bogus merge edges mtn: rebuilding 737 nodes mtn: certs in | certs out | nodes | revs out mtn:2,744 | 2,744 | 737 | 737 (The database got smaller, as mentioned in the release notes -- great work!) -rw-r--r-- 1 jeronimo jeronimo 39649280 2006-04-21 19:01 main.db -rw-r--r-- 1 jeronimo jeronimo 53411840 2006-04-21 18:48 main.db-BACKUP-BEFORE-UPGRADE OK, so I did: $ mtn db check --db main.db And I got a long list of errors: mtn: file 025956f13beceec4cca7393659b05de8e71e5bd0 unreferenced mtn: file 094b2ed953a07ff3a82efbf82b502b8035340df4 unreferenced ... mtn: revision 00f8c20566a8c25b340d03738b6b392da43fa1b8 missing branch cert mtn: revision 01192e87a971615ce36c7812d0cc4b5de2a8d8b0 missing branch cert ... mtn: revision 38a42fef05f9faab97f384c48b65ced421c9d6ef mismatched certs (1 authors 2 dates 1 changelogs) mtn: revision f24059f68e450fd6151551a3520e63e3b9072c89 missing branch cert ... mtn: warning: 38 unreferenced files mtn: warning: 209 missing certs mtn: warning: 1 mismatched certs mtn: check complete: 1,977 files; 737 rosters; 737 revisions; 3 keys; 2,744 certs mtn: total problems detected: 248 (209 serious) mtn: error: serious problems detected However, I did a checkout of one branch, and it seemed to be OK. Did something go wrong in the upgrade? Is there something else I can do to diagnose the problem? Or is it just OK? Thanks, J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Packet I/O howto
Hi.
I have been playing with packet I/O, and found that the documentation
gives commands for packet transfering, it doesn't say what exactly (and
in what order) I should do to transfer revisions between databases. I
found out, and thought I'd write this mini-howto for Monotone 0.26. I
hope it's useful.
Also, if I may add something to the wishlist... Maybe it would be nice
to have one single command for getting all packets from one revision?
Something like:
mtn automate packets_for_revision ID
That would be great!
Thanks,
J.
=
Packet I/O mini-howto.
==
We will create two databases, A and B, then create a few revisions in
A, and transfer part of them to B.
First we initialize the databases:
/--
$ mtn -d A db init
$ mtn -d B db init
\--
Now set up a branch in A:
/--
$ mtn -d A setup -b test test
\--
And let's put some revisions in that branch:
/-
$ cd test/
$ cat file
xyz
^D
$ mtn add file
$ mtn ci -m One
$ cat file2
file 2 getting in
^D
$ cat file
ERASE
^D
$ mtn add file2
$ mtn ci -m Two
$ cat file
THIRD
^D
$ mtn ci -m Three
\--
OK, that's enough Let's see what we have:
/--
$ cd ..
$ mtn -d A automate graph|awk '{print $1;}'|xargs -- mtn -d A automate toposort
$ mtn -d A automate get_revision a423db0ad651c74e41ab2529eca6f17513ccf714
format_version 1
new_manifest [b6dbdbbe0e7f41e44d9b72f9fe29b1f1a4f47f18]
old_revision []
add_dir
add_file file
content [8714e0ef31edb00e33683f575274379955b3526c]
\--
OK, one file was added in this revision. Will transfer it. Now, ORDER MATTERS!
We should transfer:
1. The fdata and fdeltas, if any
2. The rdata
3. The certs
In that order. This is because certs make reference to release data, and
release data
makes reference to file data and file deltas.
/--
mtn -d A automate packet_for_fdata 8714e0ef31edb00e33683f575274379955b3526c GO
mtn -d A automate packet_for_rdata a423db0ad651c74e41ab2529eca6f17513ccf714
GO
mtn -d A automate packets_for_certs a423db0ad651c74e41ab2529eca6f17513ccf714
GO
mtn -d B read GO
\--
OK, let's transfer one more revision:
/--
mtn -d A automate get_revision d14e89582ad9030e1eb62f563c8721be02ca0b65
format_version 1
new_manifest [48a03530005d46ed9c31c8f83ad96c4fa22b8b28]
old_revision [a423db0ad651c74e41ab2529eca6f17513ccf714]
add_file file2
content [d2178687226560032947c1deacb39d16a16ea5c6]
patch file
from [8714e0ef31edb00e33683f575274379955b3526c]
to [8b52d96d4fab6c1e56d6364b0a2673f4111b228e]
\--
OK, in this revision one we have one new file and one patch:
/--
mtn -d A automate packet_for_fdata d2178687226560032947c1deacb39d16a16ea5c6
GO2
mtn -d A automate packet_for_fdelta 8714e0ef31edb00e33683f575274379955b3526c
8b52d96d4fab6c1e56d6364b0a2673f4111b228e GO2
mtn -d A automate packet_for_rdata d14e89582ad9030e1eb62f563c8721be02ca0b65
GO2
mtn -d A automate packets_for_certs d14e89582ad9030e1eb62f563c8721be02ca0b65
GO2
mtn -d B read GO2
\--
Fine. The two revisions should be on the second database now.
You may want to check the GO* files to see what the packets look like.
/--
mtn -d A automate graph|awk '{print $1;}'|xargs -- mtn -d A automate toposort
a423db0ad651c74e41ab2529eca6f17513ccf714
d14e89582ad9030e1eb62f563c8721be02ca0b65
151f1fb125f19ebe11eb8bfe3a5798fcbea4e736
mtn -d B automate graph|ate graph|awk '{print $1;}'|xargs -- mtn -d B automate
toposort
a423db0ad651c74e41ab2529eca6f17513ccf714
d14e89582ad9030e1eb62f563c8721be02ca0b65
\--
Good! B has the two first revisions (as expected), and A has all three.
However, a checkout
of that branch on B will not work, because the certificate signatures cannot be
verified.
We need to transfer the signatures too (suppose the key used had the ID [EMAIL
PROTECTED]):
/--
mtn -d A pubkey [EMAIL PROTECTED] GO4
mtn -d B read GO4
\--
Done.
/--
$ mtn -d B mtn -d B co -b test test-B
$ ls test-B
file2 _MTN x
more test-B/file2
file 2 getting in
\--
And that's it! The revisions were successfully transfered.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
