[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Monotone-devel] Re: [long] subdirectory restrictions,
Johannes Winkelmann <=