Fossil SCM

--- src/update.c
+++ src/update.c
@@ -577,11 +577,11 @@
     zFile = db_column_text(&q;, 0);
     zFull = mprintf("%/%/", g.zLocalRoot, zFile);
     errCode = historical_version_of_file(zRevision, zFile, &record;, &isExe;,2);
     if( errCode==2 ){
       if( db_int(0, "SELECT rid FROM vfile WHERE pathname=%Q", zFile)==0 ){
-        fossil_print("UNMANAGE: %s\n", zFile);
+        fossil_print("UNMANAGED: %s\n", zFile);
       }else{
         undo_save(zFile);
         file_delete(zFull);
         fossil_print("DELETE: %s\n", zFile);
       }

drh added on 2011-08-11 01:24:21 UTC: I don't know if this is wrong or not. What it is saying is "I am going to stop managing this file now." Not "this file has not been managed previously". So I think "UNMANAGE:" without the final D is right.

bharder added on 2011-08-11 06:14:40 UTC: The scenario when I encountered this was: I had temporarily nuked part of my source tree; I knew I'd be able to recover it, so rm -fr ./fu/bar/subdir. Now, when I tried restoring it, what I did was fossil chan | grep MISSING | awk '{print "fossil revert "$2}' | sh (roughly). The missing files were displayed as fu/bar/subdir/file.a, for example, but I wasn't in the toplevel dir when trying to restore them; lets say I was in ./fu. I'd be trying to restore ./fu/fu/bar/subdir/file.a. I was initially shocked when I saw lines of UNMANAGE: .... It looked to me like it was a verb.

I'm not sure my "D" patch wouldn't be interpretted similarly if the error said "UNMANAGED: " ("oh my, these files are now unmanaged!"), but when I wrote this ticket, it seemed like a better idea. I think there may be room for improvement over both cases, upon reflection. Are we limiting ourselves to a single-word description?

I'll leave this open for now, in case there are more comments. This seems like a really, really small deal on one hand, but I think may be able to improve the user-experience, which is always a good thing.

bharder added on 2011-08-11 06:22:54 UTC: Rereading your comment drh, I think that the way I'm interpreting "manage" is "this was part of the repo; I'm now ceasing to recognize it as such: I'm unmanaging this file.", which isn't what's really happening. "Manage" is a loaded word; I'd almost rather see ENOTMANAGED (to borrow C inspired error codes). In fact, for the case I described, ENOSUCHFILE would have been more appropriate.