Re: Automatically commenting changes

[Tim X <timx@nospam.dev.null>]

Gary <help-gnu-emacs@garydjones.name> writes:

> Richard Riley wrote:
>> Gary writes:
>>> Stefan Monnier wrote:
>>>
>>>>> An editor I used long long ago had the ability to tag lines you
>>>> changed
>>>>> with your name (or some other customisable character sequence).
>
>>>> I think the way to attack such a problem nowadays is to keep your
>>>> code in a version control system (VCS), which then keeps track of
>>>> all that info for you.
>>>
>>> I do. But before I commit, or rather in the process of commiting, when
>>> there is the original file I branched from to consider, plus my
>> changes,
>>> possibly plus changes from others who have commited since I branched,
>>> things can get confusing.
>
>> git-blame
>> magit
>
> Actually I use svn. But still.
>
> It doesn't help.
>
> Sadly I am the only one using vcs (don't even get me *started* on that),
> otherwise people just send cra^H^Hode around by email and one person
> merges them into an "approved" version, similarly distributed via
> email. I then maintain my "private" subversion repo, with the merges and
> the changes that I make. Which means that 'svn blame' says I made all of
> the changes...
>
> (Okay, so kill me, I used the term "others who have commited" and it
> wasn't 100% true.)
>
Hi Gary,

If you are the one that commits everything to your private repository,
then the information on who did what is lost. As you point out, svn
blame/praise won't be able to tell you anything useful. At the same
time, since the information has essentially been lost, neither could any
sort of emacs mode help. 

However, there may be a solution, but it would involve changing your
workflow. 

I've had great success with using the git svn method. Essentially, you
can setup a git repository which will allow you to keep your own local
git based copy of the main/central svn repository. You get full
bi-directional interfaces i.e. you can pull down changes and push back
up changes (provided your allowed to write to the svn repository). This
will maintain commit information and has the added advantage, through
git support for rebasing, of keeping commits in a sane order. Git also
has support for handling patches povided via email and other very nice
features. 

While git can seem a bit daunting at first and has a few new conceptual
shifts, I find the benefits to be worth it - to some extent, it is
similar to the move from cvs to svn or from rcs to cvs - some learning
is required, but the final benefits are worth it. 

I use the blame/praise facilities using a git svn repository on a dialy
basis and have been doing so for the last 12 months. It works extremely
well. Merging and branching are much easier and git seems to be able to
handle more stuf that I previously had to handle manually with svn. At
first, I found git somewhat daunting, but soon found out that 80% of
what I needed to do was easy and straight-forward. The trick seems to be
to just focus on the functioanlity you need and don't try to digest the
full scope of options and features available in git all at once. 

Tim

-- 
tcross (at) rapttech dot com dot au