bugmonotone - Bugs: bug #29576, mtn tries to rewrite options file...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #29576: mtn tries to rewrite options file every time

Submitted by:  Jack Lloyd <randombit>
Submitted on:  Fri 16 Apr 2010 03:37:37 PM UTC  
 
Category: working copySeverity: 3 - Normal
Item Group: incorrect behaviorStatus: Fixed
Privacy: PublicAssigned to: Derek Scherger <dscherger>
Open/Closed: Closed
mtn version --full: 

monotone 0.47 (base revision: 58eca89fab6322a14c219fb377eae54e21311986)
Running on : Linux 2.6.33-gentoo-1 #1 SMP Tue Mar 2 12:42:36 EST 2010 x86_64
C++ compiler : GNU C++ version 4.4.3
C++ standard library: GNU libstdc++ version 20100121
Boost version : 1_41
SQLite version : 3.6.22 (compiled against 3.6.22)
Lua version : Lua 5.1
PCRE version : 7.9 2009-04-11 (compiled against 7.9)
Botan version : 1.8.8 (compiled against 1.8.8)
Changes since base revision:
format_version "1"

new_manifest [69563b5f6cb9e1af6a87aebd6d672e721f646026]

old_revision [58eca89fab6322a14c219fb377eae54e21311986]

Generated from data cached in the distribution;
further changes may have been made.

Mon 19 Apr 2010 09:54:58 AM UTC, comment #2:

Fixed in 5f00cba58b8c3feb72d6de28e94610a42e30465b - thanks Derek

Thomas Keller <tommyd>
Project Administrator
Sat 17 Apr 2010 07:27:11 AM UTC, comment #1:

I understand where you're heading - but the problem is the underlying "architecture" of this feature. _MTN/options is supposed to save options which the user entered on command line to avoid that he has to enter them again - while it makes no difference for it whether or not the triggered command has a readonly-style or even needs the listed options in _MTN/options or whether the usage of an option would even be considered harmful (f.e. mtn status -d path/to/other.db ends up rewriting _MTN/options even if the other db does not (!) contain the base revision of the workspace).

So if anybody wants to pick that up, we should discuss how we improve the situation here. I'd propose two changes:

1) Save any given options back to MTN/options at the very end of the execution (f.e. in monotone.cc) _after it has been clear that no exception occurred - so we don't remember possibly harmful settings.

2) Only save those options back to _MTN/options which have actually been given by the user on the command line - this would probably need a little fiddling with the <someopt>_given flag we set even for options from _MTN/options (or we leave that alone and find another way to determine which options have been given by the user and which not). Note that there is also a hook which returns default command options for a command.
Alternatively we could always save back the options to _MTN/options unless another global command line option is given, f.e. --skip-options-saving or something similar.

Thomas Keller <tommyd>
Project Administrator
Fri 16 Apr 2010 03:37:37 PM UTC, original submission:

Monotone seemingly tries to rewrite the options file every time it is run. This causes problems with running `mtn stat` or `mtn diff` in a directory where the current user does not match the user who owns the _MTN directory.

The canonical case for this is when mtn is used to maintain /etc; typically you'd want to be able to diff or stat files as a normal user, and then do manipulations (checkins, etc) using sudo. Or at least I would.

Workaround: run mtn stat/mtn diff as root. :(

Jack Lloyd <randombit>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by tommyd (Posted a comment)
  • -unavailable- added by randombit (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 Apr 2010 09:54:58 AM UTCtommydStatusNone=>Fixed
      Assigned toNone=>dscherger
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1