Re: [Monotone-devel] case insensitive file names
Richard Levitte wrote: stephen_leake> Second, why does 'update' care if some files are stephen_leake> missing? They will be restored or not as appropriate by stephen_leake> the update anyway. In the current use case, this check stephen_leake> just gets in the way. I'll start another thread for stephen_leake> that. No, 'update' doesn't restore files, it merges changes into files that exist in the workspace. If that change is a rename, it needs the original file to perform the rename. If the change is a few added lines somewhere, it needs the original file (which might have been changed in the workspace as well) to make that change. I suspect the poster might be thinking of CVS, where update will restore missing files. In CVS the usual procedure for reverting a file is to delete it and the run cvs update. To the best of my knowledge not applicable to any modern system though. Generally most systems use revert. The assumption being if you deleted a file, you had a good reason for doing so, and don't want it suddenly reappearing. Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] update and other commands vs missing files
Thomas Keller wrote: Still undecided about that - what if the file got accidently deleted? Sure, its recoverable via revert and one has to look cleanly onto the changeset one wants to commit anyways to avoid such accidential deleted files, but I'm at least completly satisfied with mtn drop --missing ... If the file was accidentally deleted (any number of reasons), and the user fails to notice before committing the change (it was only a simple one line change made in a hurry), then the die-die-die merge algorithm will ensure the file cannot be recovered to its original state. Better to be conservative and require files be explicitly dropped I think, at least until we remove the die-die-die merge algorithm. Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Comparison of Monotone and git
Bruce Stephens wrote: * History rewriting: - Git has an easy UI for re-writing history in a local repository - The re-base command that allows patch sets to be cleaned up before submission - There is no reason this couldn't be done in monotone, but it goes against the Monotone philosophy. You'd end up using a bunch of mtn kill_rev_locally' style operations that Monotone considers dangerous. This single "feature" of git has produced huge (and heated) controversy on the debian-devel (and probably other) mailing list. It seems everyone has a different idea of when re-basing is required, and when it should or should not be used. If I understand anything, some people argue that the history needs to be "clean" for future reference, some people argue it doesn't matter, while other people argue re-basing should never be used on public repositories because it messes up other branches people might be working on, while others go ahead and do just that. Personally I like monotone's model that history, once written, never changes. It is a permanent record of who did what/when/why. It it meant to be messy. Then again I skipped over large parts of these flame wars, so I might have missed something. Disclaimer: I don't really understand what this feature does. ;-) Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Comparison of Monotone and git
Brian May <[EMAIL PROTECTED]> writes: [...] > This single "feature" [rebase] of git has produced huge (and heated) > controversy on the debian-devel (and probably other) mailing > list. It seems everyone has a different idea of when re-basing is > required, and when it should or should not be used. Indeed. And not having the feature is an obvious way of avoiding the controversy. On the other hand, there's one case where it's obviously OK for me to rewrite history: when they're mine and have never left my control. With CVS, that might be something I'd do in a checkout using quilt. So I'm storing changes for convenience, and when I've got something I want to commit, I can do so. I might do the same with monotone, or (I guess) I could use kill_rev_locally (though possibly that's more awkward than using quilt). git provides suitable tools so I can just use git for the whole thing (though there are also quilt-like addons to git). But sure, it's strictly unnecessary; one could always use merge, just as you're forced to do with monotone. It just feels generally cleaner (IMHO) to "merge" the couple of changes I have locally to the new upstream version by rebasing them (basically applying the patches to the new head) rather than really merging. Mostly doing that keeps the history more linear, and (perhaps) easier to understand. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] case insensitive file names
Brian May <[EMAIL PROTECTED]> writes: > Richard Levitte wrote: >> stephen_leake> Second, why does 'update' care if some files are >> stephen_leake> missing? They will be restored or not as appropriate by >> stephen_leake> the update anyway. In the current use case, this check >> stephen_leake> just gets in the way. I'll start another thread for >> stephen_leake> that. >> >> No, 'update' doesn't restore files, it merges changes into files that >> exist in the workspace. If that change is a rename, it needs the >> original file to perform the rename. If the change is a few added >> lines somewhere, it needs the original file (which might have been >> changed in the workspace as well) to make that change. >> > I suspect the poster might be thinking of CVS, where update will > restore missing files. Ah, thanks. I was not consciously thinking of that, but that is the origin of my discomfort with monotones behavior. > In CVS the usual procedure for reverting a file is to delete it and > the run cvs update. Right. > To the best of my knowledge not applicable to any modern system > though. Generally most systems use revert. The assumption being if you > deleted a file, you had a good reason for doing so, and don't want it > suddenly reappearing. That's true. Which is why I think mtn should not require an explicit 'mtn drop' for user deleted files; it should be implied. My actual use case was this: if I have a workspace that is nominally at the head of branch 'main', and I start messing around, then realize I really should be working on branch 'experimental', I want to do: mtn "just switch to experimental, and don't bother me!" which is approximated by: mtn ls --missing > files_i_deleted.log mtn revert --missing mtn update --branch experimental some_painful_shell_script.sh files_i_deleted.log I'd rather just do 'mtn update --branch experimental' :). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] case insensitive file names
Stephen Leake schrieb: My actual use case was this: if I have a workspace that is nominally at the head of branch 'main', and I start messing around, then realize I really should be working on branch 'experimental', I want to do: mtn "just switch to experimental, and don't bother me!" which is approximated by: mtn ls --missing > files_i_deleted.log mtn revert --missing mtn update --branch experimental some_painful_shell_script.sh files_i_deleted.log I'd rather just do 'mtn update --branch experimental' :). I think I've already read the request from several other people to have a global / project local rcfile which includes default options to the user's likings - and I guess this should be fairly easy to implement as well. We'd only have to call into some lua hook "expand_command(cmd, opts, args)" f.e. right after read_options() in monotone.cc:232, in which everybody can add / change his or her favourite options. (afaik mtn already looks for _MTN/monotonerc, correct?) Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] workaround needed
I'm trying to setup ikiwiki with Fedora 9. This uses: monotone 0.39 (base revision: dedb7e96fe917e0e8a30862b38e8092eefd7afa3) There is an error coming from monotone; I've boiled it down to the following simplified sequence: [EMAIL PROTECTED] ~]$ cd /tmp [EMAIL PROTECTED] tmp]$ rm -rf jnk* [EMAIL PROTECTED] tmp]$ mtn db init --db=jnkdb.mtn [EMAIL PROTECTED] tmp]$ mtn setup jnk --branch=jnkbranch --db=jnkdb.mtn [EMAIL PROTECTED] tmp]$ cd jnk [EMAIL PROTECTED] jnk]$ mkdir foo [EMAIL PROTECTED] jnk]$ touch foo/bar [EMAIL PROTECTED] jnk]$ mtn add foo/bar mtn: adding foo to workspace manifest mtn: adding foo/bar to workspace manifest [EMAIL PROTECTED] jnk]$ mtn commit -m '' foo/bar mtn: warning: restriction excludes addition of 'foo' but includes addition of 'foo/bar' mtn: misuse: invalid restriction Is there a simple workaround for this problem in 0.39? I tried cd'ing into foo and committing bar, that works, but I'm a little nervous about messing with the path inside ikiwiki ... Many thanks in advance! Ken -- Ken Sedgwick Bonsai Software, Inc. http://www.bonsai.com/ken/ (510) 610-4162 [EMAIL PROTECTED] Public Key: http://www.bonsai.com/ken/ken.asc GPG Fingerprint: 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workaround needed
On Tue, Jun 24, 2008 at 09:20:57AM -0700, Ken Sedgwick wrote: > There is an error coming from monotone; I've boiled it down to the > following simplified sequence: ... > [EMAIL PROTECTED] jnk]$ mtn commit -m '' foo/bar > mtn: warning: restriction excludes addition of 'foo' but includes > addition of 'foo/bar' > mtn: misuse: invalid restriction You want: mtn commit -m. foo foo/bar --Jack -- Jack (John) Cummings http://mudshark.org/ PGP fingerprint: F18B 13A3 6D06 D48A 598D 42EA 3D53 BDC8 7917 F802 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workaround needed
[EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 09:20:57AM -0700, Ken Sedgwick wrote: There is an error coming from monotone; I've boiled it down to the following simplified sequence: ... [EMAIL PROTECTED] jnk]$ mtn commit -m '' foo/bar mtn: warning: restriction excludes addition of 'foo' but includes addition of 'foo/bar' mtn: misuse: invalid restriction You want: mtn commit -m. foo foo/bar Jack, Thanks! I added a "path expander" like you suggested to ikiwiki and I'm back in the race! Thanks again! Ken -- Ken Sedgwick Bonsai Software, Inc. http://www.bonsai.com/ken/ (510) 610-4162 [EMAIL PROTECTED] Public Key: http://www.bonsai.com/ken/ken.asc GPG Fingerprint: 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] ping Ludovic Brenta
I sent you more corrections to the Debian package a few weeks ago and haven't heard anything - do you have time to continue sponsoring the package? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: ping Ludovic Brenta
Zack Weinberg writes: > I sent you more corrections to the Debian package a few weeks ago and > haven't heard anything - do you have time to continue sponsoring the > package? Probably next weekend. Did you ping me earlier? I think I missed that. Sorry. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
