monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: [long] subdirectory restrictions


From: Johannes Winkelmann
Subject: Re: [Monotone-devel] Re: [long] subdirectory restrictions
Date: Sat, 2 Oct 2004 10:33:11 +0200
User-agent: Mutt/1.4.2.1i

Hi,

Sorry for being a bit late...

On Tue, Sep 21, 2004 at 07:16:06 -0400, graydon hoare wrote:
> On Mon, 20 Sep 2004 23:39:08 -0700, Nathaniel Smith 
> <address@hidden> wrote:
[...]
> >    There's also the standard pragmatic test, that asks which behavior is
> >    easier to emulate given the other... in my proposal, to get a full
> >    version diff, I say
> >      $ monotone diff
> >    and to get a diff of the current directory, I say
> >      $ monotone diff .
> 
> I do somewhat like the sound of this better. and honestly, I often do a diff
> to see what I'm about to commit, so having the system *accidentally* tell me
> that there's stuff I forgot about (which I'm going to commit) one directory
> over is a virtue in my mind.
> 
> that said, the other "standard pragmatic test" is to ask a statistically
> meaningful group of users which feels better. anyone else have a preference?
Even though the other posters have mostly agreed to the proposed
approach, I would be surprised to get a whole project's diff when doing
'monotone diff' in a subdirectory. I somehow expect commands to work on
the current working directory when not told otherwise, and find, ls,
cvs, svn all work this way. When I do a 'ls' first and a 'monotone
diff' afterwards, I'd expect the diff to be against the files I got from
ls. 
It's not that I couldn't live with a different behaviour, but since I'll
continue to use svn and certainly also ls and find on a regular base, I
will have to change "modes" on a regular base.

Regarding the standard pragmatic test of Nathaniel, I agree that it's
much harder to emulate. OTOH I usually have use a terminal where the
current working directory defines my "region of interest"; say if I have
a structure like:

project/
  src/
    lib1/
    lib2/
    bin/
  doc/


I'd have the terminal in e.g. lib1 as long as I'm hacking there; at that
time, I wouldn't be that interested in the prototype code I wrote in
lib2... once I'm about to commit, I'd either do that from the lib1
subdir, or cd one level up (I might still do a 'monotone commit lib1'
there). The case where I'm committing a whole project from a
subdirectory is one that I never use; I always change my current working
directory to cover the directories I want to commit.

Note that this is just the way I'm used to work/use revision control,
and this is obviously a bit different from others, but in my particular
case a "default to current working directory" policy would be the least
surprising behaviour, and have no real disadvantages. I just figured
that in order to get a statistically meaningful group, I'd add my two
cents two :-)

Kind regards, Johannes
-- 
Johannes Winkelmann              mailto:address@hidden
Bern, Switzerland                http://jw.tks6.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]