Suffering from CVS mindset

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Sune Foldager [mailto:cryo at cyanite.org]
>
>On 13-04-2010 17:56, Haszlakiewicz, Eric wrote:
>> One thing that might be confusing you is that mercurial has a (IMO,
very
>> annoying) default of "whole repository" for various commands, rather
>> than the more intuitive "current directory".  That means that if
you're
>> working in some directory and you only want to commit the stuff from
>> there you need to run:
>>    hg commit .
>> with the current directory explicitly specified.  Things like "hg
log"
>> do the same thing, as does "hg diff" (except there it's even more of
a
>> pain, b/c hg creates "fake" paths in the diff output), etc....
>
>Sounds like you're not ready for a distributed VCS? ;-). The
>'repository-wide' operations of Mercurial is one of its biggest
>strengths in my opinion.

What does distributed VCS have to do with the repository-wide default
for 
operations?  I don't see how there is *any* connection between the two.

The only thing I see as required for operations that work
repository-wide by 
default is the ability to figure out where the top of your repository
is, 
and if you wanted to be perverse you could even do that with CVS. 
(e.g.: while cmp -s CVS/Root ../CVS/Root ; do REPOTOP=../$REPOTOP ; done
)

>> The default log output sucks.
>
>The default output tells you what changes were made, in form of the
>commit summary. These summaries are supposed to sum up the changes. If
>your summaries read "made some changes" etc., I'd say you're not doing
>it right. That said, I always prefer glog (or log -G) over log.

Well duh.  Obviously just "made some changes" is a crappy commit
message,
but I shouldn't need to list the files I changed in my commit message;
even
a more reasonable message is often only really understandable when you
know
 the file(s) it pertains to.

hmm... my copy of mercurial doesn't seem to have a -G option.  Is that
an
extension?  What does it do?

> > The built-in "verbose" log output isn't
>> much better (e.g. it lists files, but w/o any indication of what
>> happened to each, and all on one line so it's impossible to parse
>> individual file names).
>
>?? If lists the files (but not what happened to the files) so it's
>..impossible to parse the file names?

No, I was talking about two separate things. I suppose I could have
worded 
that better:
  1) it just lists the file names, without any indication of what
happened 
to each file (i.e. modified, added, deleted, renamed, whatever)
  2) hg log -v lists all the files on one line, so if you have a file
called 
"my file", you can't distinguish between one file being changed, and two

files called "my" and "file" being changed.  (see example at the end of
this 
message)

>> Theoretically, there's a way to tweak it to do
>> things like list the changed files in a way that subversion might
>> (which, IMO, is much more useful and readable), but I was never able
to
>> get it to work quite right.
>
>If I want to see the recent changes to the repository, I'd much rather
>see 10 small entries, each with a good summary, than countless lines of
>diffs I might not even be interested in. There are tools for all those
>situations (hg status -c <rev> and hg diff -c <rev>), though.

Who said anything about diffs?  If I want diffs I can run "hg log -p".
I am 
talking about a slightly more detailed summary from which you can
actually 
see what files were changed.

eric


Example of crappy log output:
# hg init x && cd x
# echo foo > " file1"
# echo bar > "my file"
# hg add *
# hg ci -m testcommit
# hg log -v
changeset:   0:a4e0e469dc3b
tag:         tip
user:        ehaszla
date:        Thu Apr 15 17:49:57 2010 -0500
files:        file1 my file
description:
testcommit