Re: [Monotone-devel] [PATCH] mtn publish

[Ben Walton]

On 12/22/06, Nathaniel J. Smith <address@hidden> wrote:
> On Thu, Dec 21, 2006 at 10:25:35AM -0500, Ben Walton wrote:
> > I don't want the clients seeing _MTN/*.
>
> I accept your assertion, but am curious about your reasons :-).  It
> seems like _MTN/* takes completely negligible space, and provides
> potentially valuable information?

But...it's only valuable information if the clients needed to
contribute info back to a db.  In the uses I'm putting it to, it's
completely extraneous info except in my working copy.  I agree that
the space is negligible, and it certainly wouldn't hurt to have the
clients see it either...

My goal is to have cfengine on the master server periodically do an
export from the db, which will be picked up by the clients (of which
it counts itself a member too).  This would allow me to develop the
scripts completely outside of the primary repository that clients
update from.  The cfengine update script could just rm the _MTN itself
too, if found, or even do an update && rm --unknown as well.  Many
ways to skin a cat.

> > I realize that this could be done with a script also, so if you feel
> > that this is a silly feature, my feelings will not be hurt if the
> > patch isn't accepted.
>
> I don't really have any opinion either way -- I've never felt that "rm
> -rf _MTN" was particularly onerous, but hey, if abstraction gives
> people fuzzies and keeps them warm at night...

Agreed, this is just a warm fuzzy feature.

> General comments on the design follow:
>
> > The semantics are almost identical to checkout, except that it will
> > not checkout to the cwd.  It also introduces a --force option to be
> > used in the event where the publishing destination directory already
> > exists.  If the destination exists and is a file, mtn will abort...I
> > felt that this was more dangerous than overriding a directory.  An
> > existing directory is backed up and left in place.
>
> I have never seen a good reason to name an option "--force" -- the
> name conveys almost nothing about what it actually does, and so people
> inevitably end up wanting to pile other a grab bag of behaviors under
> the same switch, and users inevitably end up trying it whenever they
> see an error, just in case _this_ happens to the error that --force
> turns off...
>
> And, of course, there's the always enjoyable question of how to name
> backups, and what to do if the name is in use.  Do you actually have a
> need for the ability to clobber an existing directory with this
> command?  It seems like it would be easier to just tell users to do
> their own "rm -rf $FOO", or "[ -e $FOO ] && mv b$FOO $FOO.bak" or
> whatever particular policy they like.

Ok, point taken.  --force is likely a bad choice for the reasons
you've listed above.  Backup naming is always a challenge, no doubt.
Using the pid should avoid collissions for a while at least (unless
you hang out with Murphy), but is far from reliable in the long
run...this could be beefed up with pid.revision (where revision
increments until it hits max_int or something), but that's getting
carried away.  I'd be more inclined to rename --force to
--update-existing or similar, and completely remove the old directory
after a successful export.

...Like I said, this is about 2 lines of shell script, so if it's not
a desirable feature, we can just drop it altogether.

> -- Nathaniel


--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <address@hidden>

Unanswered questions are far less dangerous than unquestioned answers.
- The Roadside Pulpit
---------------------------------------------------------------------------------------------------------------------------