Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68677 > unrolled thread

Re: Question about Source Control

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about Source Control Cameron Simpson <cs@zip.com.au> - 2014-03-21 17:00 +1100
    Re: Question about Source Control Roy Smith <roy@panix.com> - 2014-03-21 08:23 -0400
      Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-22 04:23 +1100
      Re: Question about Source Control Tim Chase <python.list@tim.thechases.com> - 2014-03-21 12:54 -0500
      Re: Question about Source Control Tim Chase <python.list@tim.thechases.com> - 2014-03-21 12:59 -0500
      Re: Question about Source Control Cameron Simpson <cs@zip.com.au> - 2014-03-22 08:32 +1100
      Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-22 09:17 +1100

#68677 — Re: Question about Source Control

On 21Mar2014 07:40, Frank Millman <frank@chagford.com> wrote:
> "Cameron Simpson" <cs@zip.com.au> wrote in message 
> news:20140321013313.GA58343@cskk.homeip.net...
> > Someone intending to clone the project and develop will probably
> > want the whole repository; as Gregory says - they can then easily
> > push/pull with others.
> >
> > For Frank, the size of the repo is not the size of the bare code *
> > number of changesets. There are many diff-level steps in there,
> > making for a much smaller size. And code is small; really really
> > small.
> 
> Ok, I think I've got it.
> 
> To make the software available to anyone who just wants to run a stable 
> version, copy the working directory of the 'major release' repository to a 
> directory of its own, without the .hg stuff, and make it available for 
> download.

See "hg archive". It does exactly that for you. Run "hg help archive".
It will also make tarballs and other archive formats.

> For everyone else, just make the full repository available, and don't worry 
> about the size.
> 
> 'Everyone else' would include those wishing to collaborate on the project, 
> and those who just wish to keep up to date with the latest updates.
> 
> Actually my concern was not the 'size' of the full repository, but the 
> prospect of wading through thousands of changesets most of which are ancient 
> history. However, I assume that the experienced user will adopt habits such 
> as 'hg log tip:-10' to review the last 10 changesets, so it should not be a 
> problem.

Yep.

Also see "hg blame". (Run "hg help blame" for usage info.)

For example, inside my "hg/css" repository I can say:

  hg blame bin/set-x

and the output goes:

    [hg/css]fleet*> hg blame bin/set-x
     2186: #!/bin/sh
    11359: #
    11359: # Trace execution of a command.

and so on the the end of the file. That tells me when those lines
of the file were last modified (by local changeset number). You
could pick a line in the file that you're interested in and look
at log entries for that.

For example, taking "11359" from the above listing, I can go:

    [hg/css]fleet*> hg log -r 11359
    changeset:   11359:136315cc8ec5
    user:        Cameron Simpson <cs@zip.com.au>
    date:        Wed Mar 05 10:37:09 2014 +1100
    files:       bin/set-x
    description:
    set-x: add --date option to timestamp command start and end, upgrade option parsing logic

That is for the whole changeset, but it happens to affect just that one
file.

Alternatively, although there may be many many changes, for some
files it is not so noisy. You might go:

    hg log bin/set-x

to show only changes involving that particular file.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

The aim of AI is to make computers act like the ones in the movies.
        - Graham Mann

[toc] | [next] | [standalone]

#68686

In article <mailman.8348.1395381664.18130.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

>   hg blame bin/set-x
> 
> and the output goes:
> 
>     [hg/css]fleet*> hg blame bin/set-x
>      2186: #!/bin/sh
>     11359: #
>     11359: # Trace execution of a command.

There's two things hg blame doesn't do which would be useful.

First, the trivial one.  I don't want lines annotated by change number, 
I want them annotated by the name of the person who checked it in.  But, 
I'm sure that can be easily fixed with some simple post-processing 
filter, so it really falls into the bucket of "minor annoyances".

The hard thing is I don't really want to know which change most recently 
touched the line of text.  I want to know who really wrote it.  It would 
be wonderful if hg were smart enough to be able to back-track through 
the change history and ignore trivial changes like whitespace, 
refactoring a function out of one file into another, etc.  That's the 
real meat and potatoes of "blame".  I want to know who I need to hit 
over the head with a clue-by-four once I fix a bug.

[toc] | [prev] | [next] | [standalone]

#68702

On Fri, Mar 21, 2014 at 11:23 PM, Roy Smith <roy@panix.com> wrote:
> There's two things hg blame doesn't do which would be useful.
>
> First, the trivial one.  I don't want lines annotated by change number,
> I want them annotated by the name of the person who checked it in.  But,
> I'm sure that can be easily fixed with some simple post-processing
> filter, so it really falls into the bucket of "minor annoyances".
>
> The hard thing is I don't really want to know which change most recently
> touched the line of text.  I want to know who really wrote it.  It would
> be wonderful if hg were smart enough to be able to back-track through
> the change history and ignore trivial changes like whitespace,
> refactoring a function out of one file into another, etc.  That's the
> real meat and potatoes of "blame".  I want to know who I need to hit
> over the head with a clue-by-four once I fix a bug.

Hmm. 'git blame' can do both of those things, so I'd be very surprised
if 'hg blame' can't, at least with some extension(s). (The latter
feature is "git blame -w filename"; -w is a standard 'git diff' option
meaning "ignore whitespace".) But hey, if nothing else, you could
import your hg repo into git just to blame the file...

ChrisA

[toc] | [prev] | [next] | [standalone]

#68707

On 2014-03-22 04:23, Chris Angelico wrote:
> > The hard thing is I don't really want to know which change most
> > recently touched the line of text.  I want to know who really
> > wrote it.  It would be wonderful if hg were smart enough to be
> > able to back-track through the change history and ignore trivial
> > changes like whitespace, refactoring a function out of one file
> > into another, etc.  That's the real meat and potatoes of
> > "blame".  I want to know who I need to hit over the head with a
> > clue-by-four once I fix a bug.  
> 
> Hmm. 'git blame' can do both of those things, so I'd be very
> surprised if 'hg blame' can't, at least with some extension(s).
> (The latter feature is "git blame -w filename"; -w is a standard
> 'git diff' option meaning "ignore whitespace".)

A quick "hg -help blame" suggests that it has options to at least
show the author and control the ignoring of whitespace, as well as
tweak other elements:

 -u --user                list the author (long with -v)
 -f --file                list the filename
 -d --date                list the date (short with -q)
 -n --number              list the revision number (default)
 -c --changeset           list the changeset
 -l --line-number         show line number at the first appearance
 -w --ignore-all-space    ignore white space when comparing lines
 -b --ignore-space-change ignore changes in the amount of white space
 -B --ignore-blank-lines  ignore changes whose lines are all blank

I don't see a "ignore refactoring", but I'd want to chase through
those more manually.

[toc] | [prev] | [next] | [standalone]

#68708

On 2014-03-21 12:54, Tim Chase wrote:
> A quick "hg -help blame"

Sigh. Accidentally hit <enter> when I meant to hit <backspace>
with <control> down.  That is, of course "hg help blame", formerly
written there as "hg -v help blame" and accidentally sent mid-edit.

-tkc

[toc] | [prev] | [next] | [standalone]

#68716

On 21Mar2014 08:23, Roy Smith <roy@panix.com> wrote:
> In article <mailman.8348.1395381664.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
> 
> >   hg blame bin/set-x
> > 
> > and the output goes:
> > 
> >     [hg/css]fleet*> hg blame bin/set-x
> >      2186: #!/bin/sh
> >     11359: #
> >     11359: # Trace execution of a command.
> 
> There's two things hg blame doesn't do which would be useful.
> 
> First, the trivial one.  I don't want lines annotated by change number, 
> I want them annotated by the name of the person who checked it in.

From "hg help blame":

  This command is useful for discovering when a change was made and by whom.

Look at "hg blame -u" or "hg blame -uv".

> The hard thing is I don't really want to know which change most recently 
> touched the line of text.  I want to know who really wrote it.  It would 
> be wonderful if hg were smart enough to be able to back-track through 
> the change history and ignore trivial changes like whitespace, 
> refactoring a function out of one file into another, etc.  That's the 
> real meat and potatoes of "blame".  I want to know who I need to hit 
> over the head with a clue-by-four once I fix a bug.

That would probably be not too hard to script. The tricky bit might be
identifying a particular line as the same over certain diffs.

Basicly, run "hg log" for the file, and examine each of the diffs
WRT to your target line.

Refactoring raises the bar somewhat.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

I am learning that criticism is not nearly as effective as sabotage.
        - Shanti Goldstein

[toc] | [prev] | [next] | [standalone]

#68720

On Sat, Mar 22, 2014 at 8:32 AM, Cameron Simpson <cs@zip.com.au> wrote:
> Basicly, run "hg log" for the file, and examine each of the diffs
> WRT to your target line.
>
> Refactoring raises the bar somewhat.

Here's one where git and hg are a lot more different.

When I'm trying to find the origin of some line of code in a git repo,
I often make a dummy edit to it, then pull up gitk, right-click the
red "deleted" line, and hit "Show origin of this line". This will
select the commit that introduced that one line, without annotating
the whole rest of the file (often a slow job, especially on a big
file), and then I can go from the green inserted line to the
corresponding red deleted line and repeat the exercise (eg if some
trivial change was made, like renaming something). I'm trying that
workflow with "hg view", the nearest equivalent to gitk, but it's way
slower and doesn't seem to have a right-click menu at all, so I'm not
sure this is possible. Is there a convenient way to trace the origin
of one line back through a few commits?

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web