Re: [Gnu-arch-users] Mirrors and remote repositories...

[The Doctor What]

* Tom Lord (address@hidden) [040303 19:09]:
>     > Also: I'm a little unclear... Does tla not offer an oportunity to
>     > commit single files outside a changeset, like BK?  I liked that
>     > behaviour since I could make tonnes of small changes and they'd all
>     > be documented with change comments, then I could send them all as
>     > one large changeset with really well documented changes.
> 
> There's ways to approximate that functionality and so forth but -- 
> 
> How is what you describe substantially more useful than simply
> editting a log message as you go?  It's a serious question -- not
> rhetorical: the feature of BK that you mention is one I find
> interesting.

I can understand, I feel the same way (but in reverse).  To me there
are two prime benifits of the per file "deltas" and then a
"changeset" (to use BK lingo).

The first is psycological:  If you're presented an oportunity to
commit changes as you make changes, then you *can* take advantage of
it.  For me, I use one of two methods to commit things.  I'll either
open a file in emacs, check it out, edit, test, then commit that
delta, then go to the next file.  Or I might see a different issue
in the same file.  This stacks up deltas in a helpful way.
Example:
  Edit file foo.c
  Change the spelling of 'teh' to 'the'.
  Commit change with comment: "* fixed bad spelling of 'the'"
  Then I might notice that I needed to fix a logic problem.
  So I fix the problem.
  Then commit the change with comment: "* fixed logic error"

Then if I use the command line tool to commit the changeset it
offers to join up these changes like so:
foo.c:
* fixed bad spelling of 'the'
* fixed logic error

The other method I use is the citool.  I usually use it when I have
made a lot of changes and haven't had time to document each little
change.  In this case, citool is graphical and shows a colored diff
of the file that I can scroll through and document each section.
citool doesn't offer the nice auto join up like the command line
tool does, so I might use it to commit the changeset and only use
citool to commit the deltas.

The second advantage of this is that it requires you to change this
because it's part of it's mechanism.  To be honest, the
*requirement* that I do it isn't that great a feature, but when I
feel lazy, it can sometimes make me document *something*.  Which is
usually better than nothing.  Except when I'm feeling lazy and
weird, in which case my changeset comments look like: "The guinea
pig made me change the color to green." when I'm commiting work for
database accesses....(yes, no color involved).

If I had to design a dream tool.  It would optionally let me edit
and log work on smaller chunks.  But wouldn't force me to, if I
really didn't feel like it.

I'm very fond of using Emacs to do quick per file delta commits.
It's similar to the way I worked in CVS and it's very natural when
I'm in bug-hunt mode.

When I'm in developer mode (when I'm more likely to use citool),
then having a tool to help me review all the changes and enter
comments would be a big help.

Anyway, I think that's the main reason I like it.  It was weird when
I first started to use it, but I really like it now.  It follows the
way I do work really well.

If you have more questions, feel free to ask. :-)

Ciao!

-- 
"Hired thugs and murderers usually don't work for love."
                -- The Doctor Who (Seeds of Doom)

The Doctor What: Need I say more?                http://docwhat.gerf.org/
docwhat *at* gerf *dot* org                                        KF6VNC