Re: [Monotone-devel] Break after kill_rev_locally
Ludovic Brenta schrieb: Ralf S. Engelschall [EMAIL PROTECTED] writes: For me this looks like mtn db kill_rev_locally rev does not remove _all_ related information of rev and that some remaining/dangling information causes the subsequent commit to break. Hmm... Unfortunately, I was not able to repeat this with a simple test where I created a fresh database, performed three commits and killed the third commit :-( I had the same, or a very similar symptom after killing the head of a branch that happened to be a propagate (A to B) node. I then did mtn propagate B A (which was what I really intended) and got an exception. The killed revision and the new revision had the same revision ID. To correct the problem, I synced the offending database into a fresh one and could then proceed with the propagate and commit. The problem is already fixed on mainline and goes into 0.37. The roster which is attached to each revision is not removed, thus if you try to commit the same revision again it cannot store the roster (which has then the same revid) again. The fix now just checks if the roster exists before a revision is committed, and if it exists, skips this step. There have been long discussions and explanations why we do not remove the roster on kill_rev_locally, please search the mail archive if interested in the conclusions. Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pulling restricted branches
Tobias Hunger schrieb: Would it be possible to have monotone just ignore the branch and continue after giving that warning? Use the --exclude option for this. How can I change the default branch pattern used by pull? Manually giving net.venge.\* after a pull is somewhat tiresome;-) There is --set-default which sets the given arguments as standard for the next push/pull/sync. How can I find out which branch pattern is currently in use? There is the `ls vars` command. What is the recommended branch pattern for monotone.ca? net.venge.* seems to work, but I am afraid to miss out some of the cool new stuff using it;-) All the cool stuff goes to net.venge.monotone, but of course there are a couple of other branches which include experimental code (which may crash, not work or even does not compile). If you want all that as well, you should $ mtn pull monotone.ca net.venge.monotone* but you'll get a couple of other, unrelated branches then as well (monotone-viz, guitone, ...). Thanks for your time (and monotone of course!) You're welcome! Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
Thomas Keller [EMAIL PROTECTED] writes: The problem is already fixed on mainline and goes into 0.37. The roster which is attached to each revision is not removed, thus if you try to commit the same revision again it cannot store the roster (which has then the same revid) again. The fix now just checks if the roster exists before a revision is committed, and if it exists, skips this step. There have been long discussions and explanations why we do not remove the roster on kill_rev_locally, please search the mail archive if interested in the conclusions. Thanks. I approve of not removing the roster and the fix is just fine. BTW, I was not really complaining as the workaround I described (syncing into a fresh database) was rather straightforward. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pulling restricted branches
On Tuesday 09 October 2007, Thomas Keller wrote: How can I find out which branch pattern is currently in use? There is the `ls vars` command. /me thinks the original question was meant differently: There is currently no way to see what branches a mtn server is serving, if some of them are restricted and not accessable by the currently connected peer. (So, if pulling '*' doesn't work because you are not allowed to pull some branches, you don't know what pattern to use to get all other branches, but have to use oob communication for that.) - Thomas M. signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pulling restricted branches
In message [EMAIL PROTECTED] on Tue, 9 Oct 2007 14:17:17 +0200, Thomas Moschny [EMAIL PROTECTED] said: thomas.moschny On Tuesday 09 October 2007, Thomas Keller wrote: thomas.moschny How can I find out which branch pattern is currently in use? thomas.moschny thomas.moschny There is the `ls vars` command. thomas.moschny thomas.moschny /me thinks the original question was meant thomas.moschny differently: There is currently no way to see what thomas.moschny branches a mtn server is serving, if some of them are thomas.moschny restricted and not accessable by the currently thomas.moschny connected peer. thomas.moschny thomas.moschny (So, if pulling '*' doesn't work because you are not thomas.moschny allowed to pull some branches, you don't know what thomas.moschny pattern to use to get all other branches, but have to thomas.moschny use oob communication for that.) Usually, a project has an information board somewhere with the appropriate information. That's certainly true for monotone, and most certainly true for any SCM, or people wouldn't even know where to turn to share the files! 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] pulling restricted branches
Richard wrote: Usually, a project has an information board somewhere with the appropriate information. That's certainly true for monotone, and most certainly true for any SCM, or people wouldn't even know where to turn to share the files! How cool would it be, though, if montone could have comments or descriptions attached to branch labels and a command to list the existing branch labels (and their comments/descriptions). That would be kind of a table of content of a database. One could look at this and understand better which branches exist and what's in them. Is not this information best kept in the database? Isn't the database the most natural place for this kind of thing? Why split it away and keep it externally in some information board or so? From the user's point of view, that would be very good because one wouldn't have to run away and scout about in some information board. Just a thought. Cheers, Joerg ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pulling restricted branches
On Oct 9, 2007, at 2:57 PM, Joerg Bullmann wrote: Richard wrote: Usually, a project has an information board somewhere with the appropriate information. That's certainly true for monotone, and most certainly true for any SCM, or people wouldn't even know where to turn to share the files! How cool would it be, though, if montone could have comments or descriptions attached to branch labels and a command to list the existing branch labels (and their comments/descriptions). That would be kind of a table of content of a database. One could look at this and understand better which branches exist and what's in them. Is not this information best kept in the database? Isn't the database the most natural place for this kind of thing? Why split it away and keep it externally in some information board or so? From the user's point of view, that would be very good because one wouldn't have to run away and scout about in some information board. FWIW git stores (non-versioned) branch descriptions in the repository and these are extremely nice to have when setting up a gitweb server. -- Julio M. Merino Vidal [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
Le dimanche 07 octobre 2007 à 04:31 +0100, Peter Stirling a écrit : I believe I have something that can help you. I wrote a lua program that: Looks for revisions with 'bad' certificates (as reported by mtn au certs rev) which have private keys available to monotone My DB is missing keys for which i don't have the private key :/ -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ 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.
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] missing public keys
Yes, but you can just generate *new* keys (with the same name), which will invalidate all the certificates, but they aren't valid anyway (well, they were valid when they were signed but they can't be verified now, which is your problem) Once you have the new keys then you can just re-sign all the certs, and then monotone will stop complaining. If you aren't interested in maintaining the history of the other keys then you could just re-sign with your normal key (my program can't do it directly like this atm but it wouldn't take long to change). It mostly depends on your needs. Reading your OP the other people who signed certificates are no longer in the picture, so the issue of tracking 'who was responsible for this revision' for historical stuff may not be as important (to you) as the new stuff you plan to do as soon as it will stop complaining every time you invoke mtn. :) Essentially we lie to monotone to get it to believe something that we know is true. On 9 Oct 2007, at 11:25 am, Benoît Dejean wrote: Le dimanche 07 octobre 2007 à 04:31 +0100, Peter Stirling a écrit : I believe I have something that can help you. I wrote a lua program that: Looks for revisions with 'bad' certificates (as reported by mtn au certs rev) which have private keys available to monotone My DB is missing keys for which i don't have the private key :/ -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
