[Monotone-devel] Google Summer of Code 2006
Google's running Summer of Code again this year: http://code.google.com/soc They invited us back again, so I went ahead and accepted :-). They seem more organized this time around, with actual infrastructure and such. If anyone is interested in doing mentoring, you can actually sign up with some web form doohickies: http://code.google.com/soc/mentor_step1.html and help us review apps, etc. Also, to everyone: what monotone-related projects do you think would be good for a student summer project? :-) (Or, just, what projects do you think would be cool?) -- Nathaniel -- Sentience can be such a burden. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Hallo, On 4/20/06, Nathaniel Smith [EMAIL PROTECTED] wrote: Also, to everyone: what monotone-related projects do you think would be good for a student summer project? :-) (Or, just, what projects do you think would be cool?) shameless plug A Trac look-alike for Monotone! /shameless plug -- -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Nathaniel Smith schrieb: Google's running Summer of Code again this year: http://code.google.com/soc They invited us back again, so I went ahead and accepted :-). They Cool thing... but what happened last time? Did any project / code from the previous SoC went into monotone? Also, to everyone: what monotone-related projects do you think would be good for a student summer project? :-) (Or, just, what projects do you think would be cool?) Well, I'm not too familiar with SoC so I don't know how many students do see that as a part time thing and how many actually stick to the OS project, so finding suitable (smaller) projects to get them warmed up might be better than huge / complicated tasks. My idea would be to offer a project to develop a cross-platform mtn GUI (this may or may not be build off guitone and/or Qt - I'm open for other suggestions as well), while extending the automation interface would be a prerequisite for that. Tommy. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
[EMAIL PROTECTED] schrieb: or WxWindows/WxWidgets? Or Java? Or Lua? By the way, what *is* guitone? A small Qt GUI for monotone, residing in net.venge.monotone.guitone at venge.net. It currently only parses the workspace and displays status information for all directories / files in a LinCVS-alike view. Tommy. ___ 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 there, I just started playing with monotone a few days ago and still missing some GUI suitable for Windows. There is guitone, but in an early stage. Now I'm joining Thomas for helping. I do a port to guitone Qt4, but I still missing some commands in the automate interface. That's my wish: a more complete automate interface Best Regards, Ingo Maindorfer ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Google Summer of Code 2006
Alex Queiroz wrote: Also, to everyone: what monotone-related projects do you think would be good for a student summer project? :-) (Or, just, what projects do you think would be cool?) shameless plug A Trac look-alike for Monotone! /shameless plug I'd like that too. The instant sourceforge drh talked about some time ago would be really cool... Zbynek -- http://zw.matfyz.cz/ http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Google Summer of Code 2006
Thomas Keller [EMAIL PROTECTED] writes: Bruce Stephens schrieb: Eclipse/netbeans/Emacs support (improving emacs support). Adding support in Trac, or creating something similar. I second the Eclipse support idea. It would be really cool to have an Eclipse MTN plugin... =) It's already being worked on, apparently. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Google Summer of Code 2006
Mee three -peter Uses monotone for MPInu source code repository. From: Thomas Keller [EMAIL PROTECTED] Date: Thu, 20 Apr 2006 16:03:16 +0200 To: monotone-devel@nongnu.org Subject: Re: [Monotone-devel] Re: Google Summer of Code 2006 Bruce Stephens schrieb: Eclipse/netbeans/Emacs support (improving emacs support). Adding support in Trac, or creating something similar. I second the Eclipse support idea. It would be really cool to have an Eclipse MTN plugin... =) Tommy. ___ 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] One person in many places
On 7/25/05, Shaun Jackman [EMAIL PROTECTED] wrote: On 7/25/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: Nonsense. All you need to require is that each *private* key has a unique keyid. And honestly, who would want to have two private keys with the same keyid in the same database? I've run into a problem involving exactly this. Before I really understood monotone's concept of databases and keys, I created two projects each with their own db and each with their own private key, although both keys have the same keyid. I'd now like to serve both projects out of the same database, but I can't push changes from one to the other because... monotone: warning: saving public key for [EMAIL PROTECTED] to database monotone: error: another key with name '[EMAIL PROTECTED]' already exists Any suggestion on how to remedy this? Can I rename the keyid in one of the databases after the fact? With the wonder of ~/.monotone/keys this is now fairly straight forward. The two keys both had a keyid of [EMAIL PROTECTED] I renamed one of the keys to ~/.monotone/keys/[EMAIL PROTECTED] In my busybox database, which was signed with the [EMAIL PROTECTED] while it was still named [EMAIL PROTECTED], I used this SQL call to rename the key in the database: mtn db execute 'update revision_certs set keypair = [EMAIL PROTECTED] where keypair = [EMAIL PROTECTED]' I've now relegated that old key to legacy, and I sign all my new changes with [EMAIL PROTECTED] One thing I didn't expect, but I understand now, is that `mtn log' and monotone-viz still show [EMAIL PROTECTED] as the author for *all* the changes, old and new. I now understand that both front-ends are simply showing the value of the `author' cert, which hasn't changed and is still [EMAIL PROTECTED] However, that cert is now signed by the [EMAIL PROTECTED] key. This make absolute sense; Alice can certainly certify that Bob is the author of a given revision. What's interesting though, is that the UI only shows that Bob is the author, and this cert is signed, but it doesn't show *who* signed it. Now that I understand this separation of keyid and author, I'd like to use Shaun Jackman [EMAIL PROTECTED] for all my future author certs. Besides being more descriptive, this aids generating ChangeLog entires from monotone logs. Is there a LUA hook to change one's preferred author cert? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: About the maintainance of monotone
On 4/18/06, Shaun Jackman [EMAIL PROTECTED] wrote: After fixing these minor issues, the NMU package would be suitable for uploading. Would anyone like to first test it out? I've posted my monotone 0.25-0.1 packages: http://people.debian.org/~sjackman/debian/pool/main/m/monotone/ I've uploaded monotone 0.25-0.1 to the delayed 7-day queue. Without intervention from the maintainer, it will move to Debian's master queue in seven days. I've also uploaded monotone 0.26-0.1 to people.debian.org/~sjackman. I have *not* tested this binary, because I have not yet made the move to rosters. Once I have, I'll post my experience and upload 0.26-0.1 to the delayed 7-day queue. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] One person in many places
On Thu, 2006-04-20 at 09:55 -0600, Shaun Jackman wrote: Now that I understand this separation of keyid and author, I'd like to use Shaun Jackman [EMAIL PROTECTED] for all my future author certs. Besides being more descriptive, this aids generating ChangeLog entires from monotone logs. Is there a LUA hook to change one's preferred author cert? Yes, get_author(branch). Tim ___ 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: [...] Also, to everyone: what monotone-related projects do you think would be good for a student summer project? :-) (Or, just, what projects do you think would be cool?) Another one would be some kind of shelf/quilt functionality. An application is when you're in a workspace with some modifications (which, for some reason, you don't want to commit just yet), and you want to make some unrelated change (a bugfix, say). For big workspaces, it would be nice to put existing changes on to a shelf, do the bugfix, then take the changes off the shelf and continue. (GNU Arch provides this: IIRC, tla undo saves patches into a ++ type directory, and tla redo reapplies them.) On the same kind of theme, some kind of interactive commit functionality might be nice. In darcs, if you've got a workspace with a logical change together with some cruft, darcs record walks you through each change and you can choose whether to record it or not. So perhaps it might be possible to put some changes on this shelf, while keeping a subset that I want to commit soon. And maybe it would be good to keep these shelved changes in the repository, while maybe keeping them not too visible. There's some discussion here, http://colabti.de/irclogger/irclogger_log/monotone?date=2005-11-24,Thu#l140. Probably other places, too. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] One person in many places
In message [EMAIL PROTECTED] on Thu, 20 Apr 2006 09:55:54 -0600, Shaun Jackman [EMAIL PROTECTED] said: sjackman One thing I didn't expect, but I understand now, is that sjackman `mtn log' and monotone-viz still show [EMAIL PROTECTED] as sjackman the author for *all* the changes, old and new. [...] What's sjackman interesting though, is that the UI only shows that Bob is sjackman the author, and this cert is signed, but it doesn't show sjackman *who* signed it. Well, monotone-viz will show you who signed each cert. You just have to scroll the log box (bottom left one) horizontally way to the right. 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] One person in many places
On 4/20/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Thu, 20 Apr 2006 09:55:54 -0600, Shaun Jackman [EMAIL PROTECTED] said: sjackman One thing I didn't expect, but I understand now, is that sjackman `mtn log' and monotone-viz still show [EMAIL PROTECTED] as sjackman the author for *all* the changes, old and new. [...] What's sjackman interesting though, is that the UI only shows that Bob is sjackman the author, and this cert is signed, but it doesn't show sjackman *who* signed it. Well, monotone-viz will show you who signed each cert. You just have to scroll the log box (bottom left one) horizontally way to the right. I stand corrected. Thanks for pointing this out, Richard! Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Google Summer of Code 2006
On Thu, Apr 20, 2006 at 12:05:25PM -0500, Chad Walstrom wrote: Bruce Stephens [EMAIL PROTECTED] wrote: For big workspaces, it would be nice to put existing changes on to a shelf, do the bugfix, then take the changes off the shelf and continue. (GNU Arch provides this: IIRC, tla undo saves patches into a ++ type directory, and tla redo reapplies them.) Not that I'm being helpful here, I currently just do a monotone diff ++patchname; monotone revert Make the changes, then run patch on ++patchname to reapply. Not as slick as quilt/shelf functionality, obviously. I believe mercurial added an 'mg' command to do this type of thing. Neat stuff. mq. The tricky part about real quilt-style functionality is that it involves mutating the revision graph. That works fine if you make sure that the revisions you use it on only ever exist in a single repo. There's some immediate tension there, though, since one of the core parts of monotone's philosophy is to eliminate the idea of this repo, the one right here on my disk as an important thing. It also causes simple usability problems -- the quilt systems for hg and git don't (AFAIK) provide any particular way to distinguish between quilt-managed, mutable revisions and real, immutable, distributable revisions. You just sort of have to be careful what you sync. 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? -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Google Summer of Code 2006
On Thu, Apr 20, 2006 at 03:14:05PM +0100, Bruce Stephens wrote: Thomas Keller [EMAIL PROTECTED] writes: Bruce Stephens schrieb: Eclipse/netbeans/Emacs support (improving emacs support). Adding support in Trac, or creating something similar. I second the Eclipse support idea. It would be really cool to have an Eclipse MTN plugin... =) It's already being worked on, apparently. So said someone on IRC, anyway: http://colabti.de/irclogger/irclogger_log/monotone?date=2006-04-20,Thusel=143#l356 Unfortunately, the nth rule of free software is: until you see a project's code, act as if it does not and never will exist. I'd love to hear more about this project, but the person didn't give any contact address or anything (I guess they work for http://cube.ch/ ?), so until I do hear more I'm still going to put it on the SoC list :-). (sbu: If you're reading this, speak up!) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] splitting commands.cc
On Thu, Apr 20, 2006 at 08:45:03PM -0500, Timothy Brownawell wrote: There's a new branch, net.venge.monotone.split-commands, with commands.cc split into about 10 smaller files. The commands are currently grouped semi-arbitrarily by what other code the call and by what they do. Maybe part of the goal should also be to factor some of the crazy gunk at the top out into _non_ commands files? :-) This probably isn't the best division to keep it at, and it needs to be split up sanely before merging it (since moving commands between files after that will cause headaches with merging). There is also a theory that says it's more dangerous to keep it separate. If you want to minimize merging pain, you probably want to minimize how much divergence occurs, so the sooner it gets merged into mainline and new changes start being made against it instead of the old stuff, the less nasty merging will need to happen...? -- 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
Re: [Monotone-devel] splitting commands.cc
Nathaniel Smith wrote: There is also a theory that says it's more dangerous to keep it separate. If you want to minimize merging pain, you probably want to minimize how much divergence occurs, so the sooner it gets merged into mainline and new changes start being made against it instead of the old stuff, the less nasty merging will need to happen...? The first thought I had here was for the new rosters restrictions branch and how much fun merging in the changes might be. So, are we in a state where we can consider merging in the new restrictions code? Has anyone looked at it? Does it look sane? ;) I can dust it off and make sure things still work over the weekend or something. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
