"Rustom Mody" wrote in message
news:19d3ddc9-0fb9-476d-a117-e5f174eca...@googlegroups.com...
> On Monday, March 17, 2014 6:36:33 PM UTC+5:30, Frank Millman wrote:
>> Hi all
>
>> I know I *should* be using a Source Control Management system, but at
>> present I am not. I tried to set up Mercurial
On Monday, March 17, 2014 6:36:33 PM UTC+5:30, Frank Millman wrote:
> Hi all
> I know I *should* be using a Source Control Management system, but at
> present I am not. I tried to set up Mercurial a couple of years ago, but I
> think I set it up wrongly, as I got myself confused and found it mor
On 3/23/2014 10:04 PM, Chris Angelico wrote:
On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy 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
On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy 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
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
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
On 3/23/2014 6:56 PM, Chris Angelico wrote:
On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam 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 o
On 24Mar2014 11:30, Chris Angelico wrote:
> On Mon, Mar 24, 2014 at 11:19 AM, Cameron Simpson wrote:
> > I'm particularly fond of "hg record" (or the similar extension, "hg
> > crecord"), which lets you commit just parts of a modified file.
> >
> > When I'm in a debugging branch, it gradually tur
On Mon, Mar 24, 2014 at 11:19 AM, Cameron Simpson wrote:
> I'm particularly fond of "hg record" (or the similar extension, "hg
> crecord"), which lets you commit just parts of a modified file.
>
> When I'm in a debugging branch, it gradually turns into a huge diff.
> "hg record" lets me commit spe
On 24Mar2014 09:56, Chris Angelico wrote:
> On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam 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 id
On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam 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,
>
> From: Dave Angel
>To: python-list@python.org
>Sent: Sunday, March 23, 2014 3:18 AM
>Subject: Re: Question about Source Control
>
>
>Albert-Jan Roskam Wrote in message:
>>
>
>In addition to posting in html format, you have
Albert-Jan Roskam 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
--
https://mail.python.org/mailman/listinfo/python-list
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
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, wh
In article ,
Gregory Ewing wrote:
>Chris Angelico wrote:
>> You can then offer a non-source-control means of downloading that
>> specific revision.
>
>Just keep in mind the downside that you can't then
>push or pull your changes directly back into the main
>repository. You can generate a patch fi
In article ,
Tim Chase 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 p
On Sat, Mar 22, 2014 at 1:49 PM, Cameron Simpson wrote:
> You might do better to ask this kind of question on the mercurial list:
>
> http://selenic.com/mailman/listinfo/mercurial
>
> Someone there is bound to have wanted to do this kind of thing, and
> may know if there's a tool or extension th
On 22Mar2014 09:17, Chris Angelico wrote:
> On Sat, Mar 22, 2014 at 8:32 AM, Cameron Simpson 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 diffe
On Sat, Mar 22, 2014 at 8:32 AM, Cameron Simpson 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
On 21Mar2014 08:23, Roy Smith wrote:
> In article ,
> Cameron Simpson 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
On 2014-03-21 12:54, Tim Chase wrote:
> A quick "hg -help blame"
Sigh. Accidentally hit when I meant to hit
with down. That is, of course "hg help blame", formerly
written there as "hg -v help blame" and accidentally sent mid-edit.
-tkc
--
https://mail.python.org/mailman/listinfo/python-li
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 i
On Fri, Mar 21, 2014 at 11:23 PM, Roy Smith 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 fi
In article ,
Cameron Simpson 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 o
On 21Mar2014 07:40, Frank Millman wrote:
> "Cameron Simpson" wrote in message
> news:20140321013313.ga58...@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.
> >
On Fri, Mar 21, 2014 at 4:40 PM, Frank Millman wrote:
> 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.
>
> For
"Cameron Simpson" wrote in message
news:20140321013313.ga58...@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
On 21Mar2014 13:14, Chris Angelico wrote:
> On Fri, Mar 21, 2014 at 12:33 PM, Cameron Simpson wrote:
> > Regarding having Mercurial installed, that is very easy, and after
> > you've gone (eg):
> >
> > hg clone https://bitbucket.org/cameron_simpson/css
> > my-copy-of-cameron's-css
> >
> > (or
On Fri, Mar 21, 2014 at 12:33 PM, Cameron Simpson wrote:
> Regarding having Mercurial installed, that is very easy, and after
> you've gone (eg):
>
> hg clone https://bitbucket.org/cameron_simpson/css my-copy-of-cameron's-css
>
> (or wherever the public repository is published), you can of cours
On 21Mar2014 09:34, Chris Angelico wrote:
> On Fri, Mar 21, 2014 at 9:19 AM, Gregory Ewing
> > Also, unless the project is truly ancient, the
> > whole history might not be as big as you expect.
> > The code presumably grew to its present size
> > incrementally, in an approximately monotonic
> > m
On Fri, Mar 21, 2014 at 9:19 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> You can then offer a non-source-control means of downloading that
>> specific revision.
>
> Just keep in mind the downside that you can't then
> push or pull your changes directly back into the main
> repository. Y
Chris Angelico wrote:
You can then offer a non-source-control means of downloading that
specific revision.
Just keep in mind the downside that you can't then
push or pull your changes directly back into the main
repository. You can generate a patch file for the
project maintainer to apply, howe
On Thu, Mar 20, 2014 at 5:48 PM, Frank Millman wrote:
> One thing still confuses me. Over the lifetime of a project, there could be
> many thousands of changesets. Some of those could be tagged as 'major
> releases'. Someone wishing to clone the project from scratch may want to
> start from the la
"Frank Millman" wrote in message
news:lgbe6g$j9o$1...@ger.gmane.org...
>
>
> To recap my basic setup, I have machine A which holds the source
> directory, machine B which is used to edit the program, and machines B and
> C which are both used to run the program.
>
> Initially, to prove that I u
On Wed, Mar 19, 2014 at 5:41 PM, Frank Millman wrote:
> I have decided to stick with Mercurial, simply because that is what I used
> in my previous attempt and I felt comfortable with it.
That's the best reason for choosing, really.
https://github.com/Rosuav/Gypsum/commit/0f973
> Also I believe t
"Frank Millman" wrote in message
news:lg6s09$irl$1...@ger.gmane.org...
> Hi all
>
> I know I *should* be using a Source Control Management system, but at
> present I am not. I tried to set up Mercurial a couple of years ago, but I
> think I set it up wrongly, as I got myself confused and found
On Wed, Mar 19, 2014 at 1:12 PM, Tim Chase
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
> frequentl
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
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 direc
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 deali
Steven D'Aprano Wrote in
message:
> On Tue, 18 Mar 2014 19:08:17 +1100, Chris Angelico wrote:
>
>> On Tue, Mar 18, 2014 at 6:55 PM, Steven D'Aprano
>> wrote:
>>> I don't think that *version* control is the right model to describe
>>> what hg and git do, although it may be appropriate for subve
On 3/17/14 8:06 AM, Frank Millman wrote:
All my source code resides on an old Linux server, which I switch on in the
morning and switch off at night, but otherwise hardly ever look at. It uses
'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other
Linux machines.
hi Frank,
On Tue, 18 Mar 2014 19:08:17 +1100, Chris Angelico wrote:
> On Tue, Mar 18, 2014 at 6:55 PM, Steven D'Aprano
> wrote:
>> I don't think that *version* control is the right model to describe
>> what hg and git do, although it may be appropriate for subversion. hg
>> doesn't manage *versions*, it ma
On Tue, Mar 18, 2014 at 6:55 PM, Steven D'Aprano wrote:
> I don't think that *version* control is the right model to describe what
> hg and git do, although it may be appropriate for subversion. hg doesn't
> manage *versions*, it manages changes to source code ("changesets").
Meh... Is there any
On Tue, 18 Mar 2014 17:47:51 +1100, Ben Finney wrote:
> "Frank Millman" writes:
>
>> I feel that I have just not grasped the basics yet, so any assistance
>> that puts me on the right path is appreciated.
>
> Here is “Hg Init”, a tutorial for Mercurial http://hginit.com/>.
>
> (“source control
On Tue, Mar 18, 2014 at 5:47 PM, Ben Finney wrote:
> (“source control” is not the most common term for this; what we're
> talking about is a “version control system”, or VCS. But some Git users
> may disagree.)
People use different terms depending on their backgrounds, I think.
I've heard a good
"Ben Finney" wrote in message
news:85y508roiw@benfinney.id.au...
> "Frank Millman" writes:
>
>> I feel that I have just not grasped the basics yet, so any assistance
>> that
>> puts me on the right path is appreciated.
>
> Here is "Hg Init", a tutorial for Mercurial http://hginit.com/>.
>
On Tue, Mar 18, 2014 at 5:42 PM, Frank Millman wrote:
> Excuse my ignorance, but how does it actually work?
Ignorance not only excused, but welcomed. :) However, caveat: I know
how git is set up, but not hg. Someone else can fill in the details;
for now, I'll explain git and hope that hg is broad
"Andriy Kornatskyy" wrote in message
news:blu0-smtp953c8572b5ca6374830e5091...@phx.gbl...
> Frank,
>
> I would suggest start with an account on https://bitbucket.org. It
> supports private repositories so you should be good there.
>
> From other hand you can setup own infrastructure for SCM, re
"Frank Millman" writes:
> I feel that I have just not grasped the basics yet, so any assistance that
> puts me on the right path is appreciated.
Here is “Hg Init”, a tutorial for Mercurial http://hginit.com/>.
(“source control” is not the most common term for this; what we're
talking about is
"Chris Angelico" wrote in message
news:captjjmqhxh2m3-qgbelv_akgajzmeymbudly8_dkpnhrpsu...@mail.gmail.com...
> On Tue, Mar 18, 2014 at 4:39 PM, Frank Millman wrote:
>> Two quick questions -
>>
>> 1. At present the source code is kept on one machine (A), but only
>> accessed
>> from the two oth
On Tue, Mar 18, 2014 at 4:39 PM, Frank Millman 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? Ins
"Chris Angelico" wrote in message
news:CAPTjJmqPca5cnNWu8T5BZhpH665X0=mrf7bjalqvrqvmjzw...@mail.gmail.com...
> On Tue, Mar 18, 2014 at 12:06 AM, Frank Millman
> wrote:
[...]
>>
>> So where should I install the SCM, and how should I set it up so that I
>> can
>> access the latest version from
On Tue, Mar 18, 2014 at 12:06 AM, Frank Millman wrote:
> All my source code resides on an old Linux server, which I switch on in the
> morning and switch off at night, but otherwise hardly ever look at. It uses
> 'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other
> Linux
Frank,
I would suggest start with an account on https://bitbucket.org. It supports
private repositories so you should be good there.
>From other hand you can setup own infrastructure for SCM, read more here:
http://mindref.blogspot.com/2013/10/how-to-manage-git-or-mercurial.html
Thanks.
Andri
Hi all
I know I *should* be using a Source Control Management system, but at
present I am not. I tried to set up Mercurial a couple of years ago, but I
think I set it up wrongly, as I got myself confused and found it more of a
hindrance than a help. Now I am ready to try again, but I want to av
56 matches
Mail list logo
