[Monotone-devel] Re: buildfarm problem
Markus Schiltknecht wrote: Hello Lapo, what's up with your buildfarm box? It seems to reproducibly segfault during netsync. Any idea? Mhh... it also seem to do it from normal command line use, using 0.36... % mtn sy --debug ... mtn: prepared statement SELECT data FROM revisions WHERE id = ? mtn: binding 1 parameters for SELECT data FROM revisions WHERE id = ? mtn: binding 1 with value '9c4f6fce90af21fe4caaabd2c795c7c1ab3ab5c8' mtn: fatal signal: Segmentation fault: 11 this is almost certainly a bug in monotone. please send this error message, the output of 'mtn --full-version', and a description of what you were doing to monotone-devel@nongnu.org do not send a core dump, but if you have one, please preserve it in case we ask you for information from it. zsh: segmentation fault (core dumped) mtn sy --debug % gdb mtn mtn.core ... (gdb) bt #0 0x0061e853 in boost::match_results__gnu_cxx::__normal_iteratorchar const*, std::string, std::allocatorboost::sub_match__gnu_cxx::__normal_iteratorchar const*, std::string ::operator[] () #1 0x0061ec82 in boost::match_results__gnu_cxx::__normal_iteratorchar const*, std::string, std::allocatorboost::sub_match__gnu_cxx::__normal_iteratorchar const*, std::string ::operator[] () #2 0x0055f69e in std::_Rb_treestd::string, std::pairstd::string const, std::string, std::_Select1ststd::pairstd::string const, std::string , std::lessstd::string, std::allocatorstd::pairstd::string const, std::string ::_M_erase () Seems to be an issue with boost (which I upgraded recently to boost-1.34.1). -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Request for help adding monotone output to cvs2svn [was: cvs_import feature sponsored]
Graydon Hoare wrote: It probably does not require mentioning, but if possible of course I'd encourage you to do this with a clean enough interface to monotone that other projects can reuse it. While I'm always pleased to have monotone be best at something, extracting latent structure from a CVS archive is as you know research-grade inference work, and if you can condense what you learn into a reusable tool it'll probably have greater visibility and longevity. The tool you are wishing for already exists: cvs2svn [1]. All that is missing is a backend to output to monotone, but that should be hackable in a day or two. cvs2svn is evolving into a generic tool for making sense of CVS repositories and converting to other SCMs. I've refactored it considerably to allow output to other SCMs via output modules, and recently added an experimental git backend [2] in only one or two days of work. cvs2svn is a mature project that is very good at understanding almost all of CVS's many perversities. See [3] for a list of cvs2svn's main features, most of which would be helpful when converting to monotone. The emphasis is on robust conversions with no data loss, and sensible translation of CVS idioms. Its test suite contains an extensive collection of strange CVS repositories that we have collected over the years, and cvs2svn can convert all of them. It includes lots of options for customizing the conversion. I'm not a monotone user, but if anybody wants to supply the monotone expertise, I'd be happy to work together to write a monotone backend for cvs2svn. (I've already made this offer to Markus Schiltknecht but he doesn't seem interested.) I think it should be easy to get the backend running in just a day or two. Volunteers? Michael [1] http://cvs2svn.tigris.org [2] http://marc.info/?l=gitm=118592701426175w=4 [3] http://cvs2svn.tigris.org/cvs2svn.html#intro ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merge of net.venge.monotone.basic_io.inventory
I've merged net.venge.monotone.basic_io.inventory into net.venge.monotone; see 07ae9cb7bea973d20cea3ff3db935744e66e9789. I bumped interface_version in cmd_automate.cc to 6.0; this is a backward-incompatible change. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Michael Haggerty [EMAIL PROTECTED] writes: [...] (I've already made this offer [to cooperate in adding mtn support to cvs2svn] to Markus Schiltknecht but he doesn't seem interested.) I suspect because cvs2svn isn't incremental. So it's a way to do a one-time conversion of a CVS repository, but many people really want to do incremental conversions, following a CVS repository as it changes. However, it clearly has a place. It's pretty fast, and as you say, copes with all the horrors of CVS. And the new version does a decent conversion to at least git (which is close enough to mercurial/monotone/etc.), though I think it creates many unnecessary branches. (This is a specifically git thing, and I guess is a matter of taste. I think cvs2svn is creating branches in order to construct revisions corresponding to CVS tags. But then from git's point of view the branch doesn't really need a name, since the tag's pointing to it. So I think I'd leave off the branch.) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] revert_unchanged_file_preserves_mtime intermittent failure on Win32
revert_unchanged_file_preserves_mtime is failing intermittently on Win32. That is, most of the time it fails, but sometimes it passes. This test is looking at file modification times; they should either increase or not change. The failure happens when they decrease. From the test log, it looks like the times are almost random. I've tried to debug this by running ./tester -r /Gnu/foo/lua-testsuite.lua /Gnu/monotone-build_mingw/tester_dir revert_unchanged_file_preserves_mtime in gdb. But that prints nothing, and breakpoints in tester.cc mtime never trigger. I can step into the Lua interpreter, but I quickly get lost. Any hints for debugging this? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Michael Haggerty [EMAIL PROTECTED] writes: [...] cvs2svn added the unnecessary branch names because of a bug in git-fast-import. I think that problem is fixed, but I haven't gotten around to changing cvs2svn. Ah, OK. More interesting is whether the branches have to be created at all for CVS (non-branch) tags. Presumably people often tag a whole repository snapshot in CVS, in which case the original branch could be tagged rather than creating a synthetic branch only to tag it. I'm currently working on code to avoid unnecessary branches for git. OK, that's probably worth doing. For repositories which include imports, I suspect many of the tags will require a branch. I guess it would depend on how one uses CVS tags as to whether it's often the case that a branch is unnecessary. (At work we quite often (more often than I'd like) move CVS tags: we tag the repository, but as release preparation progresses we move tags on selected files as bugs get fixed. It's a part of the change control procedure.) (I don't know whether monotone makes the same distinction.) Monotone stores revisions in a DAG, and a revision is in a branch b if it has a branch cert for b attached to it. A revision may be in any number of branches (including none). Using the normal interface it's tricky to create a branchless revision; I'm not sure whether the automate feature makes it easier---probably. Unlike git, it's normal for a single branch to fork. So I'd guess a natural way to do it in monotone is to have everything on branches, but for tags where you need to, just fork off the branch. Oh, darn, that doesn't work, because the tagged revision then becomes a head of the branch. OK, it'll need to be a separate branch, I guess. (In git it's normal for a branch to contain divergence in its past, but when it actually forked each fork has to have been distinct branches.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Request for help adding monotone output to cvs2svn [was: cvs_import feature sponsored]
Hello Michael, sorry for not responding to your private mails earlier, I've been ill the last few days. Michael Haggerty wrote: Graydon Hoare wrote: It probably does not require mentioning, but if possible of course I'd encourage you to do this with a clean enough interface to monotone that other projects can reuse it. That's worth a thought, although it's certainly a second step. My primary focus currently is on monotone. While I'm always pleased to have monotone be best at something, extracting latent structure from a CVS archive is as you know research-grade inference work, and if you can condense what you learn into a reusable tool it'll probably have greater visibility and longevity. Agreed, I'm discussing the issue with Michael. The tool you are wishing for already exists: cvs2svn [1]. All that is missing is a backend to output to monotone, but that should be hackable in a day or two. I've been well aware of cvs2svn at the point I've started my cvsimport branch for monotone. Back then I've decided *not* to used it for several reasons: - it was heavily disk based, where today conversion can easily be done in memory. - it seemed to be very subversion specific in various aspects, which also targeted performance. - I wanted to learn C++, not python ;-) cvs2svn is evolving into a generic tool for making sense of CVS repositories and converting to other SCMs. I've refactored it considerably to allow output to other SCMs via output modules, and recently added an experimental git backend [2] in only one or two days of work. I'm glad that cvs2svn is also evolving. I've seen your efforts and appreciate that. Maybe cvs2svn is coming closer to being able to export to monotone. But in the meantime I've also got closer to sanitize CVS repositories. All of this process helped me a lot in understanding that process. And I'm still happy to discuss some technical issues with you. IIRC that's how we decided to work together, back then. Share algorithms and experience but not code. Okay, maybe it was rather me deciding that way... You seems to only look at this as a waste of effort. I think it very well paid off for me and for getting new inputs. cvs2svn is a mature project that is very good at understanding almost all of CVS's many perversities. See [3] for a list of cvs2svn's main features, most of which would be helpful when converting to monotone. The emphasis is on robust conversions with no data loss, and sensible translation of CVS idioms. Its test suite contains an extensive collection of strange CVS repositories that we have collected over the years, and cvs2svn can convert all of them. It includes lots of options for customizing the conversion. These are all good reasons to use cvs2svn. I'm not a monotone user, but if anybody wants to supply the monotone expertise, I'd be happy to work together to write a monotone backend for cvs2svn. (I've already made this offer to Markus Schiltknecht but he doesn't seem interested.) I think it should be easy to get the backend running in just a day or two. Maybe that's possible, yes. None the less, I don't think it will make my code obsolete. I'll get back to you with technical aspects on the cvs2svn mailing list as soon as I've caught. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Bruce Stephens wrote: Michael Haggerty [EMAIL PROTECTED] writes: [...] (I've already made this offer [to cooperate in adding mtn support to cvs2svn] to Markus Schiltknecht but he doesn't seem interested.) I suspect because cvs2svn isn't incremental. So it's a way to do a one-time conversion of a CVS repository, but many people really want to do incremental conversions, following a CVS repository as it changes. That's right, cvs2svn doesn't do incremental conversions. However, it clearly has a place. It's pretty fast, and as you say, copes with all the horrors of CVS. And the new version does a decent conversion to at least git (which is close enough to mercurial/monotone/etc.), though I think it creates many unnecessary branches. (This is a specifically git thing, and I guess is a matter of taste. I think cvs2svn is creating branches in order to construct revisions corresponding to CVS tags. But then from git's point of view the branch doesn't really need a name, since the tag's pointing to it. So I think I'd leave off the branch.) [...] cvs2svn added the unnecessary branch names because of a bug in git-fast-import. I think that problem is fixed, but I haven't gotten around to changing cvs2svn. More interesting is whether the branches have to be created at all for CVS (non-branch) tags. Presumably people often tag a whole repository snapshot in CVS, in which case the original branch could be tagged rather than creating a synthetic branch only to tag it. I'm currently working on code to avoid unnecessary branches for git. (I don't know whether monotone makes the same distinction.) Michael ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Hi, Bruce Stephens wrote: OK, that's probably worth doing. For repositories which include imports, I suspect many of the tags will require a branch. I guess it would depend on how one uses CVS tags as to whether it's often the case that a branch is unnecessary. (At work we quite often (more often than I'd like) move CVS tags: we tag the repository, but as release preparation progresses we move tags on selected files as bugs get fixed. It's a part of the change control procedure.) That's certainly a problem for monotone. Not only for CVS import, but also when importing subversion repositories. Those also don't really have tags (in the monotone sense, i.e. on exactly one revision, which cannot change underneath). This is one of the things monotone is different. Back at the time when I had to decide to use cvs2svn or not, Michael et al proposed to use subversion's dump format as a general purpose base format. That's where I've just rolled my eyes and went away. Maybe I should have been more patient in explaining the differences. (I don't know whether monotone makes the same distinction.) Monotone stores revisions in a DAG, and a revision is in a branch b if it has a branch cert for b attached to it. A revision may be in any number of branches (including none). Using the normal interface it's tricky to create a branchless revision; I'm not sure whether the automate feature makes it easier---probably. Unlike git, it's normal for a single branch to fork. So I'd guess a natural way to do it in monotone is to have everything on branches, but for tags where you need to, just fork off the branch. Oh, darn, that doesn't work, because the tagged revision then becomes a head of the branch. OK, it'll need to be a separate branch, I guess. Right. For every tag and branchpoint which cannot be matched to exactly only one revision, you'll have to add an artificial revisions which you can tag. (AFAICT, git allows such an artificial revision to have multiple parents, monotone does only allow two parentsn. So for monotone, you'll have to add multiple artificial revisions). For branchpoints, it's quite clear that such artificial revisions for those can go into the branch they initiate. But for tags, you'll probably have to create an 'artificial' branch, or not assign any branch cert to those revisions. (In git it's normal for a branch to contain divergence in its past, Uh.. what do you mean by that? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Patrick Georgi [EMAIL PROTECTED] writes: [...] There are a couple of invariants in the code that require revisions to only have to ancestors. And I think some of the routines are hardcoded for either one or two ancestors, too. OK, I was misremembering. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Markus Schiltknecht [EMAIL PROTECTED] writes: [...] Right. For every tag and branchpoint which cannot be matched to exactly only one revision, you'll have to add an artificial revisions which you can tag. (AFAICT, git allows such an artificial revision to have multiple parents, monotone does only allow two parentsn. So for monotone, you'll have to add multiple artificial revisions). I don't think monotone has such a restriction. I think it happens not to create such revisions at present, but I don't think there's any intrinsic requirement that a revision has at most two parents. I imagine an importer from cvs2svn would use automate put_revision or something, and I suspect that'll be happy with any number of parent revisions. For branchpoints, it's quite clear that such artificial revisions for those can go into the branch they initiate. But for tags, you'll probably have to create an 'artificial' branch, or not assign any branch cert to those revisions. Yes, I think the former. I think it would be natural to have them on a branch, maybe one named relative to the tag name. (Or identical to the tag name, as you did with git.) (In git it's normal for a branch to contain divergence in its past, Uh.. what do you mean by that? I mean the graph of a branch may not be linear, but will (by definition) only have one head. Such a thing will be the result of a merge, and at that point the two (or more) things being merged would normally be distinct branches. In monotone it's normal just to let a branch fork for short periods, but in git that doesn't really make sense---each of the forks is a separate branch. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Bruce Stephens schrieb: I don't think monotone has such a restriction. I think it happens not to create such revisions at present, but I don't think there's any intrinsic requirement that a revision has at most two parents. I imagine an importer from cvs2svn would use automate put_revision or something, and I suspect that'll be happy with any number of parent revisions. There are a couple of invariants in the code that require revisions to only have to ancestors. And I think some of the routines are hardcoded for either one or two ancestors, too. Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Hi Bruce, Bruce Stephens wrote: I don't think monotone has such a restriction. I think it happens not to create such revisions at present, but I don't think there's any intrinsic requirement that a revision has at most two parents. I imagine an importer from cvs2svn would use automate put_revision or something, and I suspect that'll be happy with any number of parent revisions. Yes, there is code which relies on having exactly one or two parents. AFAIK mainly the mark merge gets difficult when handling revisions with multiple parents. I agreed that revisions with multiple parents *should* be supported. Even if they are mainly useful for such imports or hand merged revisions. But one needs to think around the mark merge issues, among other probably smaller problems. Yes, I think the former. I think it would be natural to have them on a branch, maybe one named relative to the tag name. (Or identical to the tag name, as you did with git.) Agreed. One might even argue if it's necessary to the tag the head of that branch. Because obviously, that wasn't really a tag in CVS, but much more like a branch. Especially for incremental imports, that will get tricky! (In git it's normal for a branch to contain divergence in its past, Uh.. what do you mean by that? I mean the graph of a branch may not be linear, but will (by definition) only have one head. Such a thing will be the result of a merge, and at that point the two (or more) things being merged would normally be distinct branches. In monotone it's normal just to let a branch fork for short periods, but in git that doesn't really make sense---each of the forks is a separate branch. Aha, understood. I stumbled across the contain divergence in its past, which is very well possible with monotone, too. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Annotate changes break tests?
On Mon, Sep 17, 2007, Thomas Moschny wrote: Ralf S. Engelschall wrote: Yes, I second that: --brief is really not the appropriate option name here. Using --only-revs and then reverting my fix sounds reasonable. Please go for it! Done in 32f2e43b.., using --revs-only. Thanks for your efforts cleaning up this stuff even further. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] moderator requests
Lately, every time I get a notification of spam on monotone-debian (in the form of a moderator request), I go to the moderator page and it's not there. Are people just deleting them before I get to them, or is something glitched? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
On Tue, Sep 18, 2007 at 12:44:06PM +0200, Markus Schiltknecht wrote: Right. For every tag and branchpoint which cannot be matched to exactly only one revision, you'll have to add an artificial revisions which you can tag. (AFAICT, git allows such an artificial revision to have multiple parents, monotone does only allow two parentsn. So for monotone, you'll have to add multiple artificial revisions). Or just pick whichever single parent is the closest match, and write out the tag as a child of that. Mapping the exact CVS ancestry for the files in tag revisions into monotone is really far from being a high priority part of cvs conversions... and honestly making tag revisions octopus merges won't really preserve the file history in any meaningful way anyway. I'd say just put some metadata in (cvs:revision attrs, or whatever) and leave it at that. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Hi, Nathaniel Smith wrote: Or just pick whichever single parent is the closest match, and write out the tag as a child of that. That would mean adding an artificial patch (from that closest match to the tag revision you need) and an artificial revision (the one which you are tagging). To me that seems much worse than adding multiple artificial merge revisions, because those can easily be filtered away by log output and such. Not to mention incremental imports... Mapping the exact CVS ancestry for the files in tag revisions into monotone is really far from being a high priority part of cvs conversions... Not highest priority, but simple enough to achieve on the way. and honestly making tag revisions octopus merges won't really preserve the file history in any meaningful way anyway. Why not? 'mtn log' and 'mtn annotate' certainly lead to better results, than with a 'closest parent' approach. I'd say just put some metadata in (cvs:revision attrs, or whatever) and leave it at that. That should be done anyway. But those things don't turn up in logs or annotations... I think we've discussed that before. Why are you insisting on a crippled approach? Regards Markus ___ 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
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
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
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
On 19/09/2007, at 9:39 AM, J Decker 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. Hrm - if the files are auto-generated, then you should just delete them. You can re-generate them when you update back to this revision again. But you say you don't want to do that, so I assume that they have original data. In which case you should 'add' them to monotone. If you add them to monotone, then it will delete them for you when going back to the previous revision, and restore them for you when you move forward again. Other options include: * Move that directory out of the way before you update. Move it back when you return. * Use two working copies * Branch your project - use propagate to move things back and forth. This is a bit orthogonal to your specific problem, but might be useful anyway. Be well, Will:-} ___ 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
William Uther spake unto us the following wisdom: Hrm - if the files are auto-generated, then you should just delete them. You can re-generate them when you update back to this revision again. But you say you don't want to do that, so I assume that they have original data. In which case you should 'add' them to monotone. There is another possibility -- maybe they are simply expensive to generate. Several times in renaming directories in the Pidgin source tree, I've had to blow away quantities of object files which I would rather have kept, all things being equal. (They could, of course, be kept by tarring them up, removing them, renaming, and extracting or what-have-you, but they're just not *that* expensive to generate! [Pidgin isn't C++, after all... ;-)]) In such a case, it really would be nice if the non-versioned files just moved right along with the versioned files. I realize that the issue isn't quite so simple, but there *is* a third, reasonable possibility. :-) (Assuming I understood the problem correctly.) 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] Re: cannot drop non-empty directory during branch update
Ethan Blanton spake unto us the following wisdom: There is another possibility -- maybe they are simply expensive to generate. Several times in renaming directories in the Pidgin source tree, I've had to blow away quantities of object files which I would rather have kept, all things being equal. (They could, of course, be kept by tarring them up, removing them, renaming, and extracting or what-have-you, but they're just not *that* expensive to generate! [Pidgin isn't C++, after all... ;-)]) In such a case, it really would be nice if the non-versioned files just moved right along with the versioned files. [snip] (Assuming I understood the problem correctly.) Rereading, I see that I did not -- but it is a related issue, I think. 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] Re: cannot drop non-empty directory during branch update
On 19/09/2007, at 12:51 PM, Ethan Blanton wrote: William Uther spake unto us the following wisdom: Hrm - if the files are auto-generated, then you should just delete them. You can re-generate them when you update back to this revision again. But you say you don't want to do that, so I assume that they have original data. In which case you should 'add' them to monotone. There is another possibility -- maybe they are simply expensive to generate. 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 actually think something maybe could change here in mtn. When a directory should be dropped in an update, but it contains unversioned files, rather than failing at that point the versioned files should be removed and the directory left behind as a normal unversioned directory with the unversioned files in it. I think that is an optimisation though. I think the original description is better handled with two working copies. Several times in renaming directories in the Pidgin source tree, I've had to blow away quantities of object files which I would rather have kept, all things being equal. (They could, of course, be kept by tarring them up, removing them, renaming, and extracting or what-have-you, but they're just not *that* expensive to generate! [Pidgin isn't C++, after all... ;-)]) In such a case, it really would be nice if the non-versioned files just moved right along with the versioned files. Um, I don't understand. % mtn db init --db=mtn.db % mtn setup wc --branch=testbranch --db=mtn.db % cd wc % mtn mkdir testdir % cd testdir % touch addedfile % mtn add addedfile % mtn commit % touch nonaddedfile % cd .. % mtn mv testdir testdirB % ls _MTNtestdirB % ls testdirB addedfile nonaddedfile Looks like the non added file did get moved with a move. Have you had something else happen? Will:-} ___ 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
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
