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

Groups > comp.lang.python > #68483 > 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 "Frank Millman" <frank@chagford.com> - 2014-03-18 08:42 +0200
    Re: Question about Source Control Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-19 10:51 +1300
      Re: Question about Source Control Terry Reedy <tjreedy@udel.edu> - 2014-03-18 21:38 -0400
      Re: Question about Source Control Tim Chase <python.list@tim.thechases.com> - 2014-03-18 21:12 -0500
        Re: Question about Source Control albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-22 17:32 +0000
          Re: Question about Source Control Tim Chase <python.list@tim.thechases.com> - 2014-03-22 13:49 -0500
          Re: Question about Source Control Albert-Jan Roskam <fomcl@yahoo.com> - 2014-03-22 13:01 -0700
          Re: Question about Source Control Dave Angel <davea@davea.name> - 2014-03-22 22:18 -0400
          Re: Question about Source Control Albert-Jan Roskam <fomcl@yahoo.com> - 2014-03-23 07:58 -0700
          Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-24 09:56 +1100
          Re: Question about Source Control Terry Reedy <tjreedy@udel.edu> - 2014-03-23 21:26 -0400
          Re: Question about Source Control Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-24 01:42 +0000
          Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-24 13:04 +1100
          Re: Question about Source Control Terry Reedy <tjreedy@udel.edu> - 2014-03-24 00:55 -0400
      Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-19 13:34 +1100

#68483 — Re: Question about Source Control

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmqHXh2M3-QGbeLV_AkGAJzMEYmbuDLy8_dkpnhrpSUVMQ@mail.gmail.com...
> On Tue, Mar 18, 2014 at 4:39 PM, Frank Millman <frank@chagford.com> wrote:
>> Two quick questions -
>>
>> 1. At present the source code is kept on one machine (A), but only 
>> accessed
>> from the two other machines (B and C).
>>
>> Does it make sense to create the central repository on A, but *not* 
>> install
>> the SCM on A? Install separate copies of the SCM on B and C, and allow 
>> them
>> both to set up their own clones. I only develop on B, so only B would
>> 'push', but both B and C would 'pull' to get the latest version.
>
> I don't know about Mercurial, but with git, installing the software on
> A lets it work more efficiently (otherwise it has to do all the work
> remotely, ergo unnecessary traffic). Advantage of free software is
> that you don't have to check license agreements - just go ahead,
> install it everywhere. But if for some reason that would be a problem,
> you can look into running it over basic SSH or something.
>

Excuse my ignorance, but how does it actually work?

Do you set up some kind of client/server relationship, and if so, how do the 
clients (machines B and C) access the software on machine A?

I know that Mercurial can run its own web server, and clients can access it 
through http. It that what you are suggesting? That would be quite a change 
for me, as on my linux box I do all my work from the command line on a 
console.

These are the kind of stumbling blocks that prevented me from succeeding in 
my previous attempt. I have a vague recollection that I set it up on machine 
A, but then hit a problem because machines B and C both accessed the same 
directory, but with different names - on Windows, a mapped drive and on 
linux a mounted nfs directory. I had to provide a 'path' name to set up 
Mercurial in the first place, but I could not find one that suited both 
clients.

I feel that I have just not grasped the basics yet, so any assistance that 
puts me on the right path is appreciated.

Frank

[toc] | [next] | [standalone]

#68521

Frank Millman wrote:
> These are the kind of stumbling blocks that prevented me from succeeding in 
> my previous attempt. I have a vague recollection that I set it up on machine 
> A, but then hit a problem because machines B and C both accessed the same 
> directory, but with different names

For dealing with your practice of editing on one machine and
running on another, you may be best off having just *one* local
repository, residing on the shared file system. Whichever machine
you're working on, you cd to the shared directory and use hg or
git commands from there, so all the pathnames you're using are
relative.

Source control operations might be slightly slower that way,
but you'd save time by not having to update your local repo
every time you switch between editing and running, so it may
well be faster overall. In any case, if the machines involved
are on a fast local network, I wouldn't expect there to be
much difference.

-- 
Greg

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

#68532

On 3/18/2014 5:51 PM, Gregory Ewing wrote:
> Frank Millman wrote:
>> These are the kind of stumbling blocks that prevented me from
>> succeeding in my previous attempt. I have a vague recollection that I
>> set it up on machine A, but then hit a problem because machines B and
>> C both accessed the same directory, but with different names
>
> For dealing with your practice of editing on one machine and
> running on another, you may be best off having just *one* local
> repository, residing on the shared file system. Whichever machine
> you're working on, you cd to the shared directory and use hg or
> git commands from there, so all the pathnames you're using are
> relative.

At least with hg, one should best test the code in the working directory 
*before* committing to the local repository. The one local repository 
could still be a close of a master repository somewhere else. One can 
push multiple commits at once, either as the end of a work session or 
when one has done enough to become paranoid about losing work.



-- 
Terry Jan Reedy

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

#68533

On 2014-03-18 21:38, Terry Reedy wrote:
> At least with hg, one should best test the code in the working
> directory *before* committing to the local repository. 

I don't know if this is a hg-vs-git way of thinking, but I tend to
frequently commit things on a private development branch regardless
of brokenness, but once I get it working, I flatten & clean up those
changes ("rebase" in git terms, which I believe has been adopted as a
standardly-available-but-not-enabled-by-default module in hg) into
logical units of change-sets that I then test individually before
applying them to my more public-facing branch.  This produces clean
history that makes it easy for others to see what's going on.

-tkc

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

#68784

In article <mailman.8270.1395195147.18130.python-list@python.org>,
Tim Chase  <python.list@tim.thechases.com> wrote:
>On 2014-03-18 21:38, Terry Reedy wrote:
>> At least with hg, one should best test the code in the working
>> directory *before* committing to the local repository.
>
>I don't know if this is a hg-vs-git way of thinking, but I tend to
>frequently commit things on a private development branch regardless
>of brokenness, but once I get it working, I flatten & clean up those
>changes ("rebase" in git terms, which I believe has been adopted as a
>standardly-available-but-not-enabled-by-default module in hg) into
>logical units of change-sets that I then test individually before
>applying them to my more public-facing branch.  This produces clean
>history that makes it easy for others to see what's going on.

I see it this way that all code is broken to at least a small
extent, so it is stupid to not to save into source control because
code is not yet flawless.
I use RCS (!) for my eulerproject.net programs, and
I save every small milestone. There is just one important rule,
if you save code that has (severe) restrictions, keep
track of it in the submission message, otherwise you loose your
bearings.
Basically the first ten of so versions (before the tag WINNER)
just don't solve the problem.
(Of course euler problems are hard, three rewrites are not
uncommon.)

I compare the in between versions with the nails they put in
the mountainside in climbing. It is a point below which you'll
never need to slide back.

>
>-tkc

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#68790

On 2014-03-22 17:32, Albert van der Horst wrote:
> >I don't know if this is a hg-vs-git way of thinking, but I tend to
> >frequently commit things on a private development branch regardless
> >of brokenness, but once I get it working, I flatten & clean up
> >those changes ("rebase" in git terms, which I believe has been
> >adopted as a standardly-available-but-not-enabled-by-default
> >module in hg) into logical units of change-sets that I then test
> >individually before applying them to my more public-facing
> >branch.  This produces clean history that makes it easy for others
> >to see what's going on.  
> 
> I see it this way that all code is broken to at least a small
> extent, so it is stupid to not to save into source control because
> code is not yet flawless.

I agree that skipping the commits just because it might be broken is
a foolish idea.  However, with most VCS tools, your commits can look
something like

  Baseline -> A -> B -> C -> D -> E -> F -> G {head/tip}

but A, C, & E all comprise one conceptual change, while B & G are
another, and D & F cancel each other out.  You can either cherry-pick
those changes or rebase (with git or the hg plugin) so that the
history looks like

  Baseline -> (ACE) -> (BG) {head/tip}

With git, the history isn't actually discarded immediately, but
rather just gets a parallel version (which may or may not have a
reference to it; if it doesn't it will get cleaned up about a month
later according to your garbage-collection settings) so your repo
ends up looking something like

  Baseline -> A -> B -> C -> D -> E -> F -> G {orphaned or named}
        \---> (ACE) -> (BG) {head/tip}

You can then publish that conceptually clean (and hopefully
tested&working) branch while simultaneously having the full history
in the event you need it.  That said, I almost never want the
intermediate work product once I have a final clean version, so I
just let git GC that for me.

-tkc

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

#68791

[Multipart message — attachments visible in raw view] — view raw

Hi,

I can recommend the book "Pragmatic Guide to Git". Very practical and to the point:

http://www.amazon.com/Pragmatic-Guide-Git-Programmers/dp/1934356727/ref=sr_1_1/184-0142481-0484062?ie=UTF8&qid=1395518159&sr=8-1&keywords=pragmatic+guide+to+git


I addition, I read a big fat super-exhaustive book, I believe it' s this one (there are two Git books with a bat!):

http://www.amazon.com/Version-Control-Git-collaborative-development/dp/1449316387/ref=sr_1_2/184-0142481-0484062?ie=UTF8&qid=1395518159&sr=8-2&keywords=pragmatic+guide+to+git


The former is for common tasks that are not common enough to remember right away. The latter is for reference.

I only have experience with git and subversion. I like git much better. But any SCM is better than none at all.

 
Regards,

Albert-Jan




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a 

fresh water system, and public health, what have the Romans ever done for us?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 





On Saturday, March 22, 2014 7:49 PM, Tim Chase <python.list@tim.thechases.com> wrote:
 
On 2014-03-22 17:32, Albert van der Horst wrote:
>> >I don't know if this is a hg-vs-git way of thinking, but I tend to
>> >frequently commit things on a private development branch regardless
>> >of brokenness, but once I get it working, I flatten & clean up
>> >those changes ("rebase" in git terms, which I believe has been
>> >adopted as a standardly-available-but-not-enabled-by-default
>> >module in hg) into logical units of change-sets that I then test
>> >individually before applying them to my more public-facing
>> >branch.  This produces clean history that makes it easy for others
>> >to see what's going on.  
>> 
>> I see it this way that all code is broken to at least a small
>> extent, so it is stupid to not to save into source control because
>> code is not yet flawless.
>
>I agree that skipping the commits just because it might be broken is
>a foolish idea.  However, with most VCS tools, your commits can look
>something like
>
>  Baseline -> A -> B -> C -> D -> E -> F -> G {head/tip}
>
>but A, C, & E all comprise one conceptual change, while B & G are
>another, and D & F cancel each other out.  You can either cherry-pick
>those changes or rebase (with git or the hg plugin) so that the
>history looks like
>
>  Baseline -> (ACE) -> (BG) {head/tip}
>
>With git, the history isn't actually discarded immediately, but
>rather just gets a parallel version (which may or may not have a
>reference to it; if it doesn't it will get cleaned up about a month
>later according to your garbage-collection settings) so your repo
>ends up looking something like
>
>  Baseline -> A -> B -> C -> D -> E -> F -> G {orphaned or named}
>        \---> (ACE) -> (BG) {head/tip}
>
>You can then publish that conceptually clean (and hopefully
>tested&working) branch while simultaneously having the full history
>in the event you need it.  That said, I almost never want the
>intermediate work product once I have a final clean version, so I
>just let git GC that for me.
>
>
>-tkc
>
>
>
>
>
>
>
>
>
>
>
>
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list
>
>
>

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

#68800

 Albert-Jan Roskam <fomcl@yahoo.com> Wrote in message:
> 

In addition to posting in html format,  you have also set the font
 size too small for me to easily read. Reason number 12 for
 posting in text mode in a text newsgroup. 

-- 
DaveA

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

#68810

________________________________
> From: Dave Angel <davea@davea.name>
>To: python-list@python.org 
>Sent: Sunday, March 23, 2014 3:18 AM
>Subject: Re: Question about Source Control
> 
>
>Albert-Jan Roskam <fomcl@yahoo.com> Wrote in message:
>> 
>
>In addition to posting in html format,  you have also set the font
>size too small for me to easily read. Reason number 12 for
>posting in text mode in a text newsgroup. 


Ooops, sorry. Below is the email again, hopefully more readable. 

One more thing (so this is not entirely a double post!). While reading these books I found that the authors were pretty religious about Clean Commits. I mean, ok, it's not a good idea to do one huge monolithic commit each month, but I felt they were exaggerating. But maybe I'm wrong and clean commits become more important when the number of collaborators get bigger. It's just so easy to fix something, and e.g. correct that typo in a docstring while you're at it.


regards,
Albert-Jan




Hi,

I can recommend the book "Pragmatic Guide to Git". Very practical and to the point:

http://www.amazon.com/Pragmatic-Guide-Git-Programmers/dp/1934356727/ref=sr_1_1/184-0142481-0484062?ie=UTF8&qid=1395518159&sr=8-1&keywords=pragmatic+guide+to+git


I addition, I read a big fat super-exhaustive book, I believe it' s this one (there are two Git books with a bat!):

http://www.amazon.com/Version-Control-Git-collaborative-development/dp/1449316387/ref=sr_1_2/184-0142481-0484062?ie=UTF8&qid=1395518159&sr=8-2&keywords=pragmatic+guide+to+git


The former is for common tasks that are not common enough to remember right away. The latter is for reference.

I only have experience with git and subversion. I like git much better. But any SCM is better than none at all.

 Regards,

Albert-Jan

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

#68824

On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <fomcl@yahoo.com> wrote:
> One more thing (so this is not entirely a double post!). While reading these books I found that the authors were pretty religious about Clean Commits. I mean, ok, it's not a good idea to do one huge monolithic commit each month, but I felt they were exaggerating. But maybe I'm wrong and clean commits become more important when the number of collaborators get bigger. It's just so easy to fix something, and e.g. correct that typo in a docstring while you're at it.
>

It's important even with a single editor. When you go back and look at
a commit, you should be able to read the summary and know immediately
whether a particular line in it should have been edited or not.
Combining changes into a single commit makes that harder.

Commits are cheap. Do more of 'em rather than less.

ChrisA

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

#68834

On 3/23/2014 6:56 PM, Chris Angelico wrote:
> On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <fomcl@yahoo.com> wrote:
>> One more thing (so this is not entirely a double post!). While reading these books I found that the authors were pretty religious about Clean Commits. I mean, ok, it's not a good idea to do one huge monolithic commit each month, but I felt they were exaggerating. But maybe I'm wrong and clean commits become more important when the number of collaborators get bigger. It's just so easy to fix something, and e.g. correct that typo in a docstring while you're at it.
>>
>
> It's important even with a single editor. When you go back and look at
> a commit, you should be able to read the summary and know immediately
> whether a particular line in it should have been edited or not.
> Combining changes into a single commit makes that harder.
>
> Commits are cheap. Do more of 'em rather than less.

With multiple branches (as with 2.7, 3.4, and default for cpython) and 
multiple active developers (20?) commiting to those brances, commits are 
definitely not free. I would not exactly call them as cheap as you seem 
to imply either. That said, I have occasionally pushed interim changes 
that put code in an improved and stable state.

N. Coughlan has suggested improving the cpython infrastructure and 
procedures to reduce the cost of commits to encourage more people to 
make more commits (in the sense of more lines changed, not more pieces) 
and improve cpython faster.

--
Terry Jan Reedy

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

#68835

On 24/03/2014 01:26, Terry Reedy wrote:
> On 3/23/2014 6:56 PM, Chris Angelico wrote:
>> On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <fomcl@yahoo.com>
>> wrote:
>>> One more thing (so this is not entirely a double post!). While
>>> reading these books I found that the authors were pretty religious
>>> about Clean Commits. I mean, ok, it's not a good idea to do one huge
>>> monolithic commit each month, but I felt they were exaggerating. But
>>> maybe I'm wrong and clean commits become more important when the
>>> number of collaborators get bigger. It's just so easy to fix
>>> something, and e.g. correct that typo in a docstring while you're at it.
>>>
>>
>> It's important even with a single editor. When you go back and look at
>> a commit, you should be able to read the summary and know immediately
>> whether a particular line in it should have been edited or not.
>> Combining changes into a single commit makes that harder.
>>
>> Commits are cheap. Do more of 'em rather than less.
>
> With multiple branches (as with 2.7, 3.4, and default for cpython) and
> multiple active developers (20?) commiting to those brances, commits are
> definitely not free. I would not exactly call them as cheap as you seem
> to imply either. That said, I have occasionally pushed interim changes
> that put code in an improved and stable state.

And consider that this has been simplified, at one point four branches 
plus default were being supported at the same time.

>
> N. Coughlan has suggested improving the cpython infrastructure and
> procedures to reduce the cost of commits to encourage more people to
> make more commits (in the sense of more lines changed, not more pieces)
> and improve cpython faster.
>

Excellent.  The most frustrating part of CPython development from my 
viewpoint is the massive number of open issues on the bug tracker that 
have patches, but simply sit there for years doing nothing except gather 
dust.  Anything that can be done to improve this situation is IMHO long 
overdue and extremely welcome.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#68836

On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> With multiple branches (as with 2.7, 3.4, and default for cpython) and
> multiple active developers (20?) commiting to those brances, commits are
> definitely not free. I would not exactly call them as cheap as you seem to
> imply either. That said, I have occasionally pushed interim changes that put
> code in an improved and stable state.
>
> N. Coughlan has suggested improving the cpython infrastructure and
> procedures to reduce the cost of commits to encourage more people to make
> more commits (in the sense of more lines changed, not more pieces) and
> improve cpython faster.

When I call them cheap, what I mean is that there's little difference
between a single commit and 2-3 commits as a group. Yes, there's a bit
more difference when you're cherry-picking them to other branches, and
maybe an infrastructure/procedure change could help with that; but
once they're there in history, it doesn't hurt to have three separate
commits doing related work, keeping the distinct parts distinct.

ChrisA

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

#68849

On 3/23/2014 10:04 PM, Chris Angelico wrote:
> On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> With multiple branches (as with 2.7, 3.4, and default for cpython) and
>> multiple active developers (20?) commiting to those brances, commits are
>> definitely not free. I would not exactly call them as cheap as you seem to
>> imply either. That said, I have occasionally pushed interim changes that put
>> code in an improved and stable state.
>>
>> N. Coughlan has suggested improving the cpython infrastructure and
>> procedures to reduce the cost of commits to encourage more people to make
>> more commits (in the sense of more lines changed, not more pieces) and
>> improve cpython faster.
>
> When I call them cheap, what I mean is that there's little difference
> between a single commit and 2-3 commits as a group.  Yes, there's a bit
> more difference when you're cherry-picking them to other branches, and
> maybe an infrastructure/procedure change could help with that; but
> once they're there in history, it doesn't hurt to have three separate
> commits doing related work, keeping the distinct parts distinct.

Every commit to a 3.x maintenance branch (now 3.4) must be forward 
merged into the 3.(x+1) default (now the future 3.5), even if it is just 
a null merge. The point of this policy is to keep the repository in a 
coherent state. If a bug were fixed in maintenance but not default, it 
would create a regression situation, the same as if it were fixed in 
default and then broken again by a separate patch.

Part of the planned (hoped-for) change (using a system that is already 
working for another project with even more code and committers) is to 
automatically test patches on the buildbots before they are committed to 
the central repository, rather than after. Each would be tested and 
accepted or rejected separately. So each commit would have to stand on 
its own even more than now.

-- 
Terry Jan Reedy

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

#68534

On Wed, Mar 19, 2014 at 1:12 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2014-03-18 21:38, Terry Reedy wrote:
>> At least with hg, one should best test the code in the working
>> directory *before* committing to the local repository.
>
> I don't know if this is a hg-vs-git way of thinking, but I tend to
> frequently commit things on a private development branch regardless
> of brokenness, but once I get it working, I flatten & clean up those
> changes ("rebase" in git terms, which I believe has been adopted as a
> standardly-available-but-not-enabled-by-default module in hg) into
> logical units of change-sets that I then test individually before
> applying them to my more public-facing branch.  This produces clean
> history that makes it easy for others to see what's going on.

My approach to rebasing is derived from the accountancy concepts my
Dad taught me. You create transactions, invoices, whatever, and you
can freely edit them so long as they're the "current batch". It's very
clear what the current batch is and where history begins. Then when
you update that batch, it becomes history and is indelible; if you
find an error in history, you put a new transaction through that
updates it (or maybe reverses it completely, so you can then do a new
clean transaction), which will have its own date (the date of the
correction) and its own identity. [1] In git terms, that means commits
above origin/master are freely editable, but as soon as anything's
pushed, it's not to be changed. I violate that rule only very VERY
occasionally, and only with the understanding that every clone of the
repo will have to be manually updated.

The "git rebase -i" command is perfect for this - it lets you rewrite
anything that isn't pushed yet, by default. I made myself a hook
script that helps with this; between that and the "autosquash" feature
of git rebase interactive, it's easy to fiddle with unpushed changes.
Let's say you discover a typo in an unpushed commit, and go and fix
the corresponding file. As long as it's a one-file edit, and the most
recent edit to that file is the commit you want to fix up, just type:

$ git commit -amf

or

$ git commit some-file -mf

and it'll make a fixup commit marked with that commit's message. Then:

$ git rebase -i

will notice that (if autosquash is enabled) and offer to squash the
two commits together. In all cases, only unpushed commits are
considered; everything from origin/master is untouchable.

If anyone wants the script, I'm happy to share, though it is
git-specific. Porting it to hg (does hg do hooks? I'm sure it must) is
left as an exercise for the reader :)

ChrisA

[1] Linking this in with a previous thread on identity vs value: a
transaction definitely has an identity, which may or may not be
representable with some sort of database ID field. The identity might
be something like "third row of the current batch" and nothing more,
but it has one.

[toc] | [prev] | [standalone]

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

csiph-web