On 09/03/2007, at 4:58 PM, Nathaniel Smith wrote:
Then there was the problem with cvssync where it was moved to a new
server that didn't have a key generated before it was run the first
time. Rather than erroring out, it added two revs without any certs
and the scripts then synced them into
Hi all, me again :)
Using this cvssync refactor branch I've got some gotchas/bugs...
Because mtn_cvs is now using mtn automate to get at the database, it
doesn't seem to have a transaction wrapped about everything any
more. This means that if something goes wrong during an mtn_cvs
On Fri, Mar 09, 2007 at 07:11:24PM +1100, William Uther wrote:
On 09/03/2007, at 4:58 PM, Nathaniel Smith wrote:
Then there was the problem with cvssync where it was moved to a new
server that didn't have a key generated before it was run the first
time. Rather than erroring out, it added
On Fri, Mar 09, 2007 at 07:20:34PM +1100, William Uther wrote:
Because mtn_cvs is now using mtn automate to get at the database, it
doesn't seem to have a transaction wrapped about everything any
more. This means that if something goes wrong during an mtn_cvs
operation, the mtn database
On 09/03/2007, at 8:03 PM, Nathaniel Smith wrote:
On Fri, Mar 09, 2007 at 07:20:34PM +1100, William Uther wrote:
Because mtn_cvs is now using mtn automate to get at the database, it
doesn't seem to have a transaction wrapped about everything any
more. This means that if something goes wrong
William Uther wrote:
I'm not sure I can separate these neatly though. I think it is easier
for the bad keys to be an issue if you're using ssh as the transport -
it isn't checking the key of the person doing the push.
I think not: the key of the sender has nothing to do with the key that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathaniel Smith wrote:
I don't know about require as an official thing, but it's never been
possible to build monotone unless you use gmake.
BSD make doesn't accept our Makefile, that's for sure. =)
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lapo Luchini wrote:
someone may better review this:
mtn diff \
-r 6d564a26acdcfc5b1e40b0d1102d550933c76244 \
-r h:net.venge.monotone.lapo.i18n
With no (new) errors on both FreeBSD and Fedora Core 4, I'll land it
tomorrow unless stopped :P
Nathaniel Smith [EMAIL PROTECTED] writes:
But once 'mtn branch' becomes the usual way to switch branches... what
point is there in making 'commit -b foo' a shortcut for 'branch foo;
commit'? It's a tiny shortcut for a rare action.
Actually, I always assumed that because it was such a rare
On 3/8/07, Nathaniel Smith [EMAIL PROTECTED] wrote:
commit -b is problematic UI (and the source of numerous complaints)
because it gives you exactly one moment in which you have the
opportunity to switch branches; if your attention wanders while
committing, then you lose. A _lot_ of people have
db in _MTN/: -1
db in ~/.monotone: -2
I keep the db for different projects on wildly varying places:
- /etc backup: /usr/local/monotone/db (different partition)
- versioned work-in-progress:
/dir/to/work-in-progress/../work-in-progress.mtn
- other projects: /usr/local/src/db
I tend not to host
On 10/03/2007, at 3:16 AM, Lapo Luchini wrote:
William Uther wrote:
I'm not sure I can separate these neatly though. I think it is
easier
for the bad keys to be an issue if you're using ssh as the
transport -
it isn't checking the key of the person doing the push.
I think not: the key
Zack Weinberg schrieb:
And third ... what I actually *want* update to do in that circumstance
is update to the head of the branch that *would* be in _MTN/options if
I hadn't gone and munged it. I do this when I have set up a working
copy but then not had time to make any actual changes, so it's
On 3/7/07, William Uther [EMAIL PROTECTED] wrote:
On 07/03/2007, at 3:04 PM, William Uther wrote:
A developer here was working at a remote site. He took a copy of
the db but not a copy of his key. He generated himself a new key
(using the same key id as his normal key), and committed
14 matches
Mail list logo
