Development tools and practices for Pythonistas
snorble
My current tools:
Python, gvim, OS file system
My current practices:
When I write a Python app, I have several unorganized scripts in a
directory (usually with several named test1.py, test2.py, etc., from
random ideas I have tested), and maybe a todo.txt file. Then I hack
away, adding features in a semi-random order. Then I get busy with
other things. Maybe one week I spend 20 hours on development. The next
week, no time on development. A few weeks later when I have some time,
I'm excited to get back to making progress, only to find that I have
to spend 30-60 minutes figuring out where I left off. The code is
usually out of sync with todo.txt. I see people who release new
versions and bug fixes, so I sometimes will create a new directory and
continue working from that copy, because it seems like the thing to
do. But if I ever made something worth releasing, and got a request
like, "I have problems with the 2.0 version. Can you send me the old
1.1 version?" I'd be like, "uhhh... let me hunt through my files by
hand and get back to you in a month". I'm thinking I can do a lot
better than this.
I am aware of tools like version control systems, bug trackers, and
things like these, but I'm not really sure if I need them, or how to
use them properly. I think having some organization to all of this
would help me to make more consistent progress, and spend less time
bringing myself up to speed after some time off.
I really like the idea of having a list of features, and tackling
those features one at a time. I read about people who do this, and
each new features gets a new minor version number. It sounds very
organized and clean. But I'm not really sure of the best way to
achieve this. Mainly I think I just need some recommendations to help
create a good mental map of what needs to happen, and mapping jargon
to concepts. Like, "each feature gets its own directory". Or with a
version control tool, I don't know if a feature maps to a branch, or a
commit?
I appreciate any advice or guidance anyone has to offer.
rusi
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them,
You either dont want version control....
> But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.
Or you do!
> or how to use them properly.
So the best advice would be: Forget python (for a while) and study one
(modern distributed) version control system:
http://en.wikipedia.org/wiki/Distributed_revision_control
From Joel Spolsky's http://joelonsoftware.com/items/2010/03/17.html
With distributed version control, the distributed part is actually not
the most interesting part.
The interesting part is that these systems think in terms of changes,
not in terms of versions.
bug-trackers are a bit of overkill for a solo developer. However...
> My current tools:
> Python, gvim, OS file system
Hand in hand with a DVCS, you need to add a testing framework.
Martin P. Hellwig
<cut explanation>
I would strongly advice to get familiar with:
- Lint tools (like PyLint)
- Refactoring
- Source Control Systems (like Mercurial Hg)
- Unit Testing with Code Coverage
Followed by either writing your own toolset that integrates all of the
above or start learning an IDE that has that stuff built-in (my personal
preference is the latter with my current IDE being PyDev (Eclipse)).
Yes you will be less productive for a couple of weeks, but I promise you
that once you know the above you win that time back very shortly, or if
you are as chaotic as me, within a week :-).
--
mph
Thomas Rachel
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file. Then I hack
> away, adding features in a semi-random order. Then I get busy with
> other things. Maybe one week I spend 20 hours on development. The next
> week, no time on development. A few weeks later when I have some time,
> I'm excited to get back to making progress, only to find that I have
> to spend 30-60 minutes figuring out where I left off. The code is
> usually out of sync with todo.txt.
That happens...
> I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.
That is another subject (IMO), and you are right: you can do a very lot
better, using the right tools.
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly.
I have been using several VCS for about 5 or 6 years now, and I can only
tell you that, once started using them, you will wonder how you ever got
along without them.
> I think having some organization to all of this
> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.
I don't see how these tools will help to get up to date the way you
describe it - but all other issues are well coped with using a VCS. I
personally started with cvs (don't do that!), then worked with svn (do
that only if you really need that), then got working with hg
(Mercurial), which is a very good thing.
Say, you have a certain development progress, and you add a new feature.
Then you do all the changes, including increasing the version number.
The changes you just have done are one changeset which you commit,
providing a good commit message. If you have a version which you ship
out, you give it a tag. In this way, you can easily change from 2.0 you
are working on to 1.5 requested by the customer.
Thomas
Jean-Michel Pichavant
applications.
Make sure it's worth the pain though, these tools are not that easy to
administrate (the usage is pretty simple).
JM
CM
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
>
> My current practices:
>
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file.
First, give your files meaningful names. test1.py, test2.py...no
wonder you have to spend an hour just figuring out where you left
off. Imagine instead if these were modules called
DiskAccessUtilities.py and UserPreferencesPanel.py. You should also
use highly descriptive names in naming classes and functions, too,
with functions being verbs and don't be afraid of long(ish) function
names like AddNewCustomerToDatabase()
> Then I hack away, adding features in a semi-random order.
I'd spend an hour with your TODO list and break it into priority
categories, like High, Med, Low, and It Would Be Nice, and then take
them strictly in that order. I'd also date the issues so you have a
sense for how long something has been waiting to be fixed.
> Then I get busy with other things. Maybe one week I spend 20 hours > on development. The next week, no time on development. A few
> weeks later when I have some time, I'm excited to get back to making
> progress, only to find that I have to spend 30-60 minutes figuring out
> where I left off.
I would try to not stop in the middle of creating a new feature or
fixing a bug, but try to finish it out before taking a week off. This
way, when you come back, you can just tackle something from the High
Priority stack and not have to figure out where you were.
> The code is usually out of sync with todo.txt.
That's just a matter of being disciplined. When I fix a bug, I simply
cut the bug from the TODO part to the DONE part of the .txt file,
nearly every time. It requires no effort compared to actually fixing
the bug, yet it feels satisfying to get that text moved.
> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.
Are you documenting your code? That can help (I need to get better
about that as well). Also, are things broken down into modules that
are self-contained? That also can help much. Is the TODO.txt always
open while you are working? It should be. Lastly, keeping some kind
of notebook or even Post-Its or a bulletin board over your desk with
notes as to what's next and where to hunt in your code to get at it
should help. Imagine if you take two weeks off, come back, want to
work on the project, and you find this note on your bulletin board:
"In the CustomersPanel.py module, add support for a wxSearchCtrl
(search bar) that searches the Former_Customers table in the main
database..." Now you are ready to jump right in!
> I really like the idea of having a list of features, and tackling
> those features one at a time. I read about people who do this, and
> each new features gets a new minor version number.
Is that true? I'm under the impression that projects do a bunch of
changes (bug fixes, and new features) and then release a new version
that has a decent amount of changes. I don't think people want tons
of versions of most projects around, but that each release should have
an appreciable amount of good changes.
> to concepts. Like, "each feature gets its own directory".
I guess it depends on your project, but that sounds needlessly complex
and way too tough with a VCS. I'd say just don't go there.
Once you use a VCS you will probably settle into a better pattern, but
things like good naming, documenting, notes, prioritizing features/
bugs, and roadmaps don't magically go away. Software development
takes long range thinking and some organizational discipline.
Che
CM
> and way too tough with a VCS. I'd say just don't go there.
(Whoops, I meant way too tough *without* a VCS, not with)
Algis Kabaila
> Am 26.04.2011 16:39, schrieb snorble:
> > When I write a Python app, I have several unorganized
> I don't see how these tools will help to get up to date the
> way you describe it - but all other issues are well coped
> with using a VCS. I personally started with cvs (don't do
> that!), then worked with svn (do that only if you really
> need that), then got working with hg (Mercurial), which is a
> very good thing.
>
> Thomas
Thomas, have you tried bzr (Bazaar) and if so do you consider hg
(Mercurial) better?
And why is it better? (bzr is widely used in ubuntu, which is
my favourite distro at present).
TIA,
OldAl.
--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
Algis Kabaila
And read your own emails *before* sending them :)
Actually, CM has given some very good advice! As I am probably
the oldest person on this list, so my penny's worth is that some
going over old stuff is good - learning is repetitious and
memory is not going to get better with age, so learn to live
with it (it being the frailty of memory...)
Chris Angelico
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> usually out of sync with todo.txt. I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?"
As other people have said, version control is very handy. I use git
myself, but imho the choice of _which_ VCS you use is far less
important than the choice of _whether_ to use one.
As to the todo file - I tend to keep only vague ideas in a separate
file. Any todo that can be logically associated with a code file or,
especially, a particular piece of code, goes in that source file:
def function(parms):
# TODO: This should check if Foo matches Bar and shortcut the computation
...
I have a very strict format: T, O, D, O, literal ASCII, always
uppercase. Makes it easy to grep (and I try to avoid "todo" in
lower-case, which means I can use a case-insensitive search if I
choose).
Additionally, if there's any task that will require checking of
multiple parts of the code, I'll create a keyword for it. For
instance, if I'm considering adding a local cache to an application to
reduce database traffic, I might do this:
//TODO CACHE: This will need to update the cache
...
//TODO CACHE: Read from cache instead
...
//TODO CACHE: Would this affect the cache?
... etc
The benefits of having the comments right beside the code cannot be
underestimated. Comments are far less likely to get out of sync if
they stare you in the face while you're changing the code - this is
why doxygen and friends are so useful.
Ultimately, it all comes down to discipline, and how important the
project is to you. At work, I have a lot of disciplines; we have a
wiki where stuff gets documented, we have source control, we have
daily backups (as well), etc, etc, etc. For little home projects, it's
not usually worth the effort. Take your pick, where do you want to go?
Chris Angelico
Dan Stromberg
<jeanm...@sequans.com> wrote:
> You can have a look at SVN and bugzilla, they are free SCM & bug tracker
> applications.
> Make sure it's worth the pain though, these tools are not that easy to
> administrate (the usage is pretty simple).
http://trac.edgewall.org/ is purportedly pretty easy to set up - I've
only used it, not set it up. Trac gives you SVN and an issue tracker.
It has plugins for other source control systems.
Thomas Rachel
> Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> (Mercurial) better?
I have played around with bzr, but afterwards more with hg which gave me
a better beeling (don't know why)...
Thomas
Ben Finney
> As other people have said, version control is very handy. I use git
> myself, but imho the choice of _which_ VCS you use is far less
> important than the choice of _whether_ to use one.
True enough. But the modern crop of first-tier VCSen – Bazaar, Git,
Mercurial – are the ones to choose from. Anoyone recommending a VCS tool
that has poor merging support (such as Subversion or, heaven help us,
CVS) is doing the newcomer a disservice.
Learn the basics in all three of those, and learn one of them well. My
choice is Bazaar, because it has a very friendly command-line interface
and has excellent support for repositories created by all the others :-)
> def function(parms):
> # TODO: This should check if Foo matches Bar and shortcut the computation
> ...
>
> I have a very strict format: T, O, D, O, literal ASCII, always
> uppercase. Makes it easy to grep (and I try to avoid "todo" in
> lower-case, which means I can use a case-insensitive search if I
> choose).
Note that following that specific convention will match the default in
many programmers's text editors for highlighting those entries to bring
them to the programmer's attention. The defaults for PyLint also report
such comments in the code.
> Ultimately, it all comes down to discipline, and how important the
> project is to you. At work, I have a lot of disciplines; we have a
> wiki where stuff gets documented, we have source control, we have
> daily backups (as well), etc, etc, etc. For little home projects, it's
> not usually worth the effort. Take your pick, where do you want to go?
The two practices above – use a modern VCS, maintain TODO items such
that the computer can report them automatically – are so useful and so
inexpensive that I think anyone aspiring to become a good programmer is
foolish if they omit them on any project.
--
\ “If you make people think they're thinking, they'll love you; |
`\ but if you really make them think, they'll hate you.” —Donald |
_o__) Robert Perry Marquis |
Ben Finney
Algis Kabaila
> Chris Angelico <ros...@gmail.com> writes:
> > As other people have said, version control is very handy. I
> > use git myself, but imho the choice of _which_ VCS you use
> > is far less important than the choice of _whether_ to use
> > one.
>
> True enough. But the modern crop of first-tier VCSen –
> Bazaar, Git, Mercurial – are the ones to choose from.
> Anoyone recommending a VCS tool that has poor merging
> support (such as Subversion or, heaven help us, CVS) is
> doing the newcomer a disservice.
>
1. Work on an existing project that is based on Python. The
"Launchpad" of ubuntu has a great environment for a project.
There are many existing projects in which to participate. Even
Bazaar's GUI version is programmed in Python with PyQt for the
GUI proper. You will get a lot out of participation in an
existing project, probably a lot more than you input.
Ultimately it is how much you input that is of of most benefit
to you yourself.
2. I failed to see questions and suggestions of platform to work
from. Your experience, interests, and computer platform will
determine what is useful to you and what is less useful.
3. Finally, it is important to have a project about which you
can master enough enthusiasm to persist. "What project "
depends very much on item 2.
May the favourable wind fill your sails,
Tim Chase
> Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> (Mercurial) better?
>
> my favourite distro at present).
Each of the main 3 (bzr, hg, git) have advantages and
disadvantages. As Ben (and others?) mentions, it's best to learn
one of these instead of starting with something like Subversion
or worse (CVS or worse, *shudder* MS Visual SourceSafe)
Bazaar (bzr)
============
launchpad.net popular for hosting
Pros:
- some Ubuntu interactions (such as launchpad) easier
- a rigorous focus on correctness
- written in Python (with a small optional bit of C)
- easy-to-use interface (CVS-ish)
- good cross-platform support
Cons:
- was slow, though I understand they've worked on improving this
Protocols:
- custom/smart protocol
- http
- sftp
- ftp
- rsync (via plugin)
Mercurial (hg)
==============
BitBucket is popular for hosting
Pros:
- speedy
- written in Python (with a small optional bit of C)
- easy-to-use interface (CVS-ish)
- fairly compact repositories
- EXCELLENT documentation via online book
- chosen by Python as the repository of choice
- good cross-platform support
Cons:
- no biggies that I've found
Protocols:
- http
- ssh
Git (git)
=========
GitHub is popular for hosting
Pros:
- a *lot* of popular projects use it (Linux kernel)
- fast
- fairly compact repositories
- good documentation (though somewhat scattered)
Cons:
- interface diverges from the "CVS standards"
- (was?) not native on
- repositories require periodic maintenance using git gc
- Win32 support is/was a little clunky
- interface was under tumultuous change for a while (though it
seems to have stabilized now)
Protocols:
- custom/smart protocol
- http
- sftp
- ftp
So that said, I've become a Mercurial user because the interface
was close to SVN which I used previously, and it was speedy on my
older machines. If bzr has come up to comparable speed, I'd be
game to probe it again. I just don't care for git's command-line
UI, but that's a personal preference thing (just like I prefer
vi/vim over emacs, but acknowledge there are lots of smart folks
on the other side, too).
-tkc
For at least hg vs. git, see
http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast
Ben Finney
> Bazaar (bzr)
> ============
> launchpad.net popular for hosting
> Pros:
> - some Ubuntu interactions (such as launchpad) easier
> - a rigorous focus on correctness
> - written in Python (with a small optional bit of C)
> - easy-to-use interface (CVS-ish)
> - good cross-platform support
- Launchpad is free software (so anyone could run their own instance to
host Bazaar repositories).
- Merges preserve all revision data, but history displays don't show
merged revisions by default. (This obviates most of the need for
history-altering commands in other VCSen to “tidy up” the revision
data: it's tidy already by default.)
- Very smooth interaction with “foreign” VCS repositories, especially
Subversion.
- Supports a wide range of workflows, without forcing peers to the same
workflow.
- Especially: Supports “centralised” (Subversion-style) VCS workflow
without losing any of the distributed advantages.
- Treats files, and filename changes, as first-class citizens in the
revision data. (Git and some others use fallible heuristics to figure
those out after-the-fact instead of recording the data.)
> Cons:
> - was slow, though I understand they've worked on improving this
Right, that's not a count against Bazaar for at least the last several
versions (since 2009 at least). Bazaar is easily fast enough for
anything people use, say, Mercurial for.
Cons:
- Repository formats were changing frequently for a while, leaving a
legacy of confusion (fixed now, but the confusion is still a black
mark).
- Limited developer base, because of Canonical's community-hostile
“contribution agreement” requirements.
- Currently only one big public full-featured hosting of Bazaar
repositories: Launchpad.net.
- The most advanced web UI to browse Bazaar repositories, “loggerhead”,
is somewhat lacking compared to the ones at Git and Mercurial hosting
sites.
> Mercurial (hg)
> ==============
> BitBucket is popular for hosting
> Pros:
> - speedy
This isn't a significant advantage for Mercurial against Git (which is
much faster) or Bazaar (which is easily as fast as Mercurial).
> - fairly compact repositories
Again, this isn't a significant advantage for Mercurial over either of
Git or Bazaar.
> - chosen by Python as the repository of choice
As I understand it, the decision was down to Bazaar or Mercurial, which
were each close enough in technical and workflow assessment that the
decision was made on personal preference. Fair enough, and it does give
another reason *now* to use Mercurial, but not due to any particular
advantage in Mercurial.
> Cons:
> - no biggies that I've found
- (Anecdotal) Merge algorithm sometimes fails catastrophically.
- Merged revisions aren't hidden, leading users to alter history.
> Protocols:
> - http
> - ssh
> Git (git)
> =========
> GitHub is popular for hosting
Unlike GitHub, Gitorious is a free-software Git hosting provider.
> Pros:
> - a *lot* of popular projects use it (Linux kernel)
> - fast
> - fairly compact repositories
> - good documentation (though somewhat scattered)
Hmm. Can't really overcome the rampant NIH syndrome: there is a lot that
shouldn't *need* so much documentation if the interface were better
designed from the start. I wouldn't count this as a pro for Git.
> Cons:
> - interface diverges from the "CVS standards"
- Terminology and command-line API gratuitously arcane (I'm reminded of
GNU Arch, *shudder*).
- Merged revisions aren't hidden, leading users to alter history.
> So that said, I've become a Mercurial user because the interface was
> close to SVN which I used previously, and it was speedy on my older
> machines. If bzr has come up to comparable speed, I'd be game to probe
> it again.
I recommend doing so.
--
\ “If I haven't seen as far as others, it is because giants were |
`\ standing on my shoulders.” —Hal Abelson |
_o__) |
Ben Finney
rusi
> On 04/26/2011 01:42 PM, Algis Kabaila wrote:
>
> > Thomas, have you tried bzr (Bazaar) and if so do you consider hg
> > (Mercurial) better?
>
> > And why is it better? (bzr is widely used in ubuntu, which is
> > my favourite distro at present).
>
> Each of the main 3 (bzr, hg, git) have advantages and
> disadvantages. As Ben (and others?) mentions, it's best to learn
> one of these instead of starting with something like Subversion
> or worse (CVS or worse, *shudder* MS Visual SourceSafe)
<pros and cons of bzr, git, mercurial snipped>
The distributed revision control page on wikipedia (bottom)
http://en.wikipedia.org/wiki/Distributed_revision_control
in addition to these, mentions fossil -- something I had not heard of
till now.
Its claims seem to match the OPs lightweight requirements more closely
than any other:
(from above link)
---------------------------
Fossil is cross-platform; its source code compiles on Linux, Mac OS X
and Microsoft Windows. It is not only capable of distributed version
control like Git and Mercurial but also supports distributed bug
tracking, a distributed wiki and a distributed blog mechanism all in a
single integrated package. With its built-in and easy-to-use web
interface, Fossil simplifies project tracking and promotes situational
awareness. A user may simply type "fossil ui" from within any check-
out and Fossil automatically opens the user's web browser in a page
that gives detailed history and status information on that project.
--------------------------
Well so much for the claims :-)
What's the facts? Anyone with any experiences on this?
alex23
> What's the facts? Anyone with any experiences on this?
No experience, but I'm rather torn over Fossil. On the one hand, it
feels like NIH writ large; on the other hand, it's a DVCS with Trac-
like features in a standalone executable less than 1MB in size...by
the author of sqlite.
Gour-Gadadhara Dasa
snorble <sno...@hotmail.com> wrote:
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
I'm also starting with Python after abandoning idea to use D for our
desktop GUI application.
We plan to use Python + Qt along with Cython extensions and wrapping
external C library.
I'm interested which Python mode can you recommend for Emacs:
a) python.el
b) python-mode.el or
c) 'new' python.el (https://github.com/fgallina/python.el)
considering our needs above and desire to use IPython running
Emacs-23.2 on FreeBSD?
Sincerely,
Gour
--
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Ben Finney
> Tim Chase <pytho...@tim.thechases.com> writes:
> > Mercurial (hg)
> > ==============
[…]
> > Cons:
> > - no biggies that I've found
>
> - (Anecdotal) Merge algorithm sometimes fails catastrophically.
I'm going to retract this one point. Merging is not as clear as in
Bazaar, but not enough to count against Mercurial – and certainly not
“fail”.
> - Merged revisions aren't hidden, leading users to alter history.
This still stands as a point against Mercurial (and against Git).
--
\ “Always code as if the guy who ends up maintaining your code |
`\ will be a violent psychopath who knows where you live.” —John |
_o__) F. Woods |
Ben Finney
rusi
> On Tue, 26 Apr 2011 07:39:41 -0700 (PDT)
>
> > I'm not a Pythonista, but I aspire to be.
>
> > My current tools:
>
> > Python, gvim, OS file system
>
> I'm also starting with Python after abandoning idea to use D for our
> desktop GUI application.
>
> We plan to use Python + Qt along with Cython extensions and wrapping
> external C library.
>
> I'm interested which Python mode can you recommend for Emacs:
>
> a) python.el
>
> b) python-mode.el or
Thats what I use.
>
> c) 'new' python.el (https://github.com/fgallina/python.el)
Looks interesting -- first time I am hearing...
Gour-Gadadhara Dasa
rusi <rusto...@gmail.com> wrote:
> > b) python-mode.el or
>
> Thats what I use.
Upon hearing there is some bug in 23.2 branches with this mode, I've
switched to 'emacs-devel' port and will start with this mode as well.
Thanks.
Jean-Michel Pichavant
> Mercurial – are the ones to choose from. Anoyone recommending a VCS tool
> that has poor merging support (such as Subversion or, heaven help us,
> CVS) is doing the newcomer a disservice.
>
> True enough. But the modern crop of first-tier VCSen – Bazaar, Git,
to use.
That would not be a such bad advice for a beginner with VCS systems.
JM
Chris Angelico
<jeanm...@sequans.com> wrote:
> For a single user, there would be no merge issue. And svn is very simple to
> use.
> That would not be a such bad advice for a beginner with VCS systems.
As someone who for years had "nightly backups and renamed files" as
his only VCS, I would advise beginners to pick up a VCS that they can
learn, master, and then use widely, not one that will be restricted to
solo work (forcing them to learn a different system when they join
some other project). There's no particular benefit in learning older
systems, is there? (I never learned CVS or SVN; my first is git, and
it's the only one I've used to any great extent.)
Oh, and rolling your own VCS can work in specific situations, but it's
probably going to work out a lot more efficient to use a well-known
one, even if it does have a learning curve. I have a few places where
I should probably migrate things to git.
Chris Angelico
Jean-Michel Pichavant
suitable for solo work than git.
Git is just the current buzz about VCS. I guess some people are
switching to it without really knowing what's going on.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
I tried to search for indicators about VCS usage without finding any but
I think that svn is still one the most used VCS. Anyway it's not about
which one is the most popular, but which one fits your need the best.
For the OP, that would be SVN IMO.
JM
Anssi Saari
> For a single user, there would be no merge issue.
Really? What about a single user with many computers and environments?
I find myself merging files on occasion because I edited them
separately and forgot to check in changes before doing more edits on a
different computer.
Ben Finney
> Ben Finney wrote:
> > Mercurial – are the ones to choose from. Anoyone recommending a VCS tool
> > that has poor merging support (such as Subversion or, heaven help us,
> > CVS) is doing the newcomer a disservice.
> > True enough. But the modern crop of first-tier VCSen – Bazaar,
> > Git,
> For a single user, there would be no merge issue. And svn is very
> simple to use.
Bazaar and Mercurial are also simple to use, and you won't have to
un-learn them when you want a good VCS for collaboration.
> That would not be a such bad advice for a beginner with VCS systems.
I disagree; a beginner can just as easily learn a better VCS and avoid
the bad habits that come along with lesser tools.
--
\ “Theology is the effort to explain the unknowable in terms of |
`\ the not worth knowing.” —Henry L. Mencken |
_o__) |
Ben Finney
Jean-Michel Pichavant
are not easy to solve. With a single user most of the merge will be
solved automatically by any decent VCS.
JM
Thomas Rachel
> You're mistaking, SVN is not restricted to solo work. However it's more
> suitable for solo work than git.
Why?
I personally found hg much better than svn. That's why I migrated all my
projects.
Thomas
Tim Chase
> Ben Finney wrote:
>> Mercurial – are the ones to choose from. Anoyone
>> recommending a VCS tool that has poor merging support (such
>> as Subversion or, heaven help us, CVS) is doing the newcomer
>> a disservice.
>
> True enough. But the modern crop of first-tier VCSen – Bazaar,
> is very simple to use.
There have been plenty of times I've needed to merge in SVN as a
solo developer. Usually I'll branch off maint. branches and spin
out feature branches. For the maint. branches, I want to apply
hot-fixes to the branch and then merge those hot-fixes into the
dev mainline. For the feature branches, I want to be able to
flip between mainline development and feature development without
one interfering with the other, but then easily pull changes from
one to the other.
And it's always been a pain. While I understand more recent SVN
releases should auto-mark things in a way that merging is less
painful, I find that it doesn't come remotely close to the ease
with which I can merge in other systems.
-tkc
Tim Chase
> Tim Chase<pytho...@tim.thechases.com> writes:
>> Bazaar (bzr)
>> ============
>> - was slow, though I understand they've worked on improving this
>
> Right, that's not a count against Bazaar for at least the last several
> versions (since 2009 at least). Bazaar is easily fast enough for
> anything people use, say, Mercurial for.
Glad to hear. That was my biggest beef with bzr when I tried it
(c. 2008), so if they've got that working well, it's worth my
time to revisit. Do you have a reference for timing improvements
against version number ("in version x.y, action Z took N ms; in
version x.[y+1], action Z took N-M ms")? I'm running Debian
Stable and sometimes it takes a little while for these features
to trickle down. But I *hope* changes in 2009 would have made it
in by now :)
>> Git (git)
>> =========
>> Pros:
>> - good documentation (though somewhat scattered)
>
> Hmm. Can't really overcome the rampant NIH syndrome: there is a lot that
> shouldn't *need* so much documentation if the interface were better
> designed from the start. I wouldn't count this as a pro for Git.
Yeah, I've encountered that aspect of the abundant documentation
on Git. :)
>> So that said, I've become a Mercurial user because the interface was
>> close to SVN which I used previously, and it was speedy on my older
>> machines. If bzr has come up to comparable speed, I'd be game to probe
>> it again.
>
> I recommend doing so.
Thanks for giving me something to do this weekend. :)
-tkc
Ben Finney
Indeed. The only thing left that Subversion is better at than the three
modern top-tier VCSen is working with existing Subversion legacy
repositories. Even for that, ‘bzr-svn’ and ‘git-svn’ work admirably
well.
--
\ “Nullius in verba” (“Take no-one's word for it”) —motto of the |
`\ Royal Society, since 1663-06-30 |
_o__) |
Ben Finney
Martin Schöön
I am a hardware development guy and do very little software development.
I have been vaguely aware of tools for version control but inspired by
this thread I have started looking at Mercurial.
My humble contribution (from my boss really) since I have not seen it
mentioned here:
http://code.google.com/p/gource/ (I have zero experience of gource so
there is no point in asking me questions)
/Martin
Ben Finney
> This has been a pretty informative thread so far. Please keep it coming.
> I am a hardware development guy and do very little software development.
> I have been vaguely aware of tools for version control but inspired by
> this thread I have started looking at Mercurial.
After my passionate Bazaar evangelism? :-)
I seriously recommend anyone looking for a modern VCS to give Bazaar a
decent trial. It's the one I've found newcomers learn most easily, and
it's astoundingly flexible as one's needs with it grow.
--
\ “I'm a born-again atheist.” —Gore Vidal |
`\ |
_o__) |
Ben Finney
Tim Chase
>> This has been a pretty informative thread so far. Please keep it coming.
>> I am a hardware development guy and do very little software development.
>> I have been vaguely aware of tools for version control but inspired by
>> this thread I have started looking at Mercurial.
>
> After my passionate Bazaar evangelism? :-)
I must say my takeaway from the thread was (1) check back in on
Bazaar to see if the speed is better than I remember and (2)
Fossil, wha? wow!
-tkc
Daniel Kluev
> Martin Schöön <martin...@gmail.com> writes:
>
> I seriously recommend anyone looking for a modern VCS to give Bazaar a
> decent trial. It's the one I've found newcomers learn most easily, and
> it's astoundingly flexible as one's needs with it grow.
>
When I was deciding what DVCS I should use for personal projects, Bzr
was first thing I tried. It was quite uncomfortable experience after
svn, esp. with branches and merges, working not the way I was
expecting it to.
Mercurial, on the contrary, did exactly what I was expecting it to,
and was overall very easy to learn.
--
With best regards,
Daniel Kluev
Hans Georg Schaathun
How easy and reliable is it to import my svn version history into
one of the three big DVCS-s mentioned here?
I am fairly happy with svn, but then I use it more as a backup system
and a means to synchronise multiple systems. Something better would
not hurt, but loosing the version history would ...
I am particularly interested in git, not because of any qualities it
may have but because that's what my colleague pushes, and he seems
to be pushing our students into it, so it would be useful for me to be
familiar with it.
--
:-- Hans Georg
Tim Chase
> How easy and reliable is it to import my svn version history
> into one of the three big DVCS-s mentioned here?
I'd say that one of the things SVN has going for it is that it's
the lingua-franca of VCSes, so just about everything (especially
the 3 big names mentioned in this thread: hg, bzr, git) can talk
to svn pretty uneventfully. As a matter of fact, last I checked,
Django is hosted in SVN, but most of the developers use DVCS
tools to check in/out from the main repository to their own local
hg/bzr/git repos, do their work locally (with the option to work
offline, branch/merge easily, etc), and then push changesets back
up when they have a patch they're happy with.
-tkc
Ben Finney
> How easy and reliable is it to import my svn version history into
> one of the three big DVCS-s mentioned here?
Bazaar's support for Subversion repositories is great (it requires the
‘bzr-svn’ plug-in, of course). Use the ‘svn-import’ subcommand to import
an entire Subversion repository to a Bazaar repository with all branches
and history intact.
--
\ “Your [government] representative owes you, not his industry |
`\ only, but his judgment; and he betrays, instead of serving you, |
_o__) if he sacrifices it to your opinion.” —Edmund Burke, 1774 |
Ben Finney
Kevin Walzer
It's written by the author of SQLite, D. Richard Hipp. It's not as
well-known as some of the other DCVS's, but the Tcl/Tk language projects
have moved their core development to it (http://core.tcl.tk). This is
relevant to Python because Tkinter is part of the stlib.
There aren't any huge sites like Github providing Fossil hosting, but
here is one site: http://chiselapp.com/
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
D'Arcy J.M. Cain
Ben Finney <ben+p...@benfinney.id.au> wrote:
> Bazaar's support for Subversion repositories is great (it requires the
> ‘bzr-svn’ plug-in, of course). Use the ‘svn-import’ subcommand to import
> an entire Subversion repository to a Bazaar repository with all branches
> and history intact.
Anyone know how to go the other way? I recently converted all my
projects over to svn from cvs and then took over another project that
uses bzr. I would prefer everything to be in the same system.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Hans Georg Schaathun
<pytho...@tim.thechases.com> wrote:
: I'd say that one of the things SVN has going for it is that it's
: the 3 big names mentioned in this thread: hg, bzr, git) can talk
: to svn pretty uneventfully. As a matter of fact, last I checked,
: Django is hosted in SVN, but most of the developers use DVCS
: tools to check in/out from the main repository to their own local
: hg/bzr/git repos, do their work locally (with the option to work
: offline, branch/merge easily, etc), and then push changesets back
: up when they have a patch they're happy with.
I am not sure I get the implications right. Are you suggesting that
I could keep my svn server, switch to a DVCS client, and reap the
benefits?
--
:-- Hans Georg
Daniel Kluev
in our university for software design and software testing courses,
and fossil seems to be perfect match, thanks for sharing.
Tim Chase
Yep...some are plugins while others are stock/native, but you can
read your fill at
Git:
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Mercurial:
http://mercurial.selenic.com/wiki/WorkingWithSubversion
Bazaar:
http://doc.bazaar.canonical.com/plugins/en/svn-plugin.html
-tkc
Martin Schöön
> Martin Schöön <martin...@gmail.com> writes:
>
>> This has been a pretty informative thread so far. Please keep it coming.
>> I am a hardware development guy and do very little software development.
>> I have been vaguely aware of tools for version control but inspired by
>> this thread I have started looking at Mercurial.
>
> After my passionate Bazaar evangelism? :-)
>
> I seriously recommend anyone looking for a modern VCS to give Bazaar a
> decent trial. It's the one I've found newcomers learn most easily, and
> it's astoundingly flexible as one's needs with it grow.
>
I'll take look but so far I have found Mercurial pretty easy to get to
grips with. But then I have only done fairly trivial stuff.
/Martin
Hans Georg Schaathun
<jeanm...@sequans.com> wrote:
: I was talking about merge *issue* i.e merge resulting in conflicts that
: solved automatically by any decent VCS.
Exactly, and with svn that can be a true nightmare when directories
are involved. The rumour is that git handles this much better.
I call it a rumour not because I doubt it (I don't), but because
I have not seen for myself.
--
:-- Hans Georg
Ben Finney
> Exactly, and with svn that can be a true nightmare when directories
> are involved. The rumour is that git handles this much better.
Any of the top-tier distributed VCS (Bazaar, Git, Mercurial) handle
branching and merging very well. They have to, because branching and
merging is much more frequent and casual in a distributed VCS.
A lone developer using such a VCS reaps the benefits of this by getting
good merging support.
--
\ “If consumers even know there's a DRM, what it is, and how it |
`\ works, we've already failed.” —Peter Lee, Disney corporation, |
_o__) 2005 |
Ben Finney
CM
> A lone developer using such a VCS reaps the benefits of this by getting
> good merging support.
While we're on the topic, when should a lone developer bother to start
using
a VCS? At what point in the complexity of a project (say a hobby
project, but
a somewhat seriousish one, around ~5-9k LOC) is the added complexity
of
bringing a VCS into it worth it?
I've been making changes to code and saving changes to the same
files,
but backing up on Dropbox, which keeps 30 days of previous saves.
I've rarely had to resort to undoing code by calling up a previous
save.
I test each new change as it is made to see if it breaks anything
(not
automatic testing, though), and I don't collaborate with anyone else
as
yet.
Should I bother to try a VCS?
Shawn Milochik
first file in my project. If you're in the habit of committing then you
can easily rollback missteps. If you're in the habit of making branches
you can experiment without breaking the currently-working code.
Roy Smith
<ad197191-042c-468a...@s4g2000yql.googlegroups.com>,
CM <cmpy...@gmail.com> wrote:
> While we're on the topic, when should a lone developer bother to start
> using a VCS?
No need to use VCS at the very beginning of a project. You can easily
wait until you've written 10 or 20 lines of code :-)
> Should I bother to try a VCS?
Absolutely. Even if you don't need it for a small one-person project,
it's a good habit to get into.
If you haven't used any, my recommendation would be hg. Partly because
it's powerful, and partly because it's relatively easy to use. The
other popular choice these days would be git. Hg and git are pretty
similar, and between the two of them probably cover 90% of current
usage. Unless you've got a specific reason to try something else (i.e.
a project you're interested in uses something else), those seem like the
only two reasonable choices.
Hans Georg Schaathun
<cmpy...@gmail.com> wrote:
: While we're on the topic, when should a lone developer bother to start
: using
: a VCS? At what point in the complexity of a project (say a hobby
: project, but
: a somewhat seriousish one, around ~5-9k LOC) is the added complexity
: of
: bringing a VCS into it worth it?
You are asking the wrong question. It depends relatively little on the
number of lines, and much more on what you are likely to do with it.
One thing is certain. If you are ever going to want to use a VCS,
you can just as well start yesterday. Using a VCS is not an extra
hassle to use. Only an added hassle to get started with.
Personally I use the VCS as
1) My backup system; naturally doing incremental backups only.
2) A means to synchronise multiple boxes (not just my laptop and
my desktop, sometimes a linux and a mac system, and dedicated
number crunchers too), and merge changes made out of synch.
3) The possibility to make one branch to run a suite of jobs
which may take a week or more, and still continue development
independently on the main branch.
As you can see, the number of lines is irrelevant. 1-2 mean that
everything is VC-d, not only code for which the VCS is meant.
And 3 is of course about what kind of code.
I branch rather little. Programming is not my day job -- nor my
main hobby, and I simply have not got the capacity to keep track
of multiple branches. Even at 12-15kloc I have little use of
the VCS for its intended purposes. If you take your development
project more seriously, you may do more of that within the first
500 loc...
But then, using VCS is not sufficient. You need to /think/ VC.
In other words, taking up a VCS when the system is large enough
to require it is too late. You need time to learn the thinking.
--
:-- Hans Georg
Martin Schöön
> On Fri, 29 Apr 2011 20:21:58 -0700 (PDT), CM
> <cmpy...@gmail.com> wrote:
>: While we're on the topic, when should a lone developer bother to start
>: using
>: a VCS? At what point in the complexity of a project (say a hobby
>: project, but
>: a somewhat seriousish one, around ~5-9k LOC) is the added complexity
>: of
>: bringing a VCS into it worth it?
>
> You are asking the wrong question. It depends relatively little on the
> number of lines, and much more on what you are likely to do with it.
>
Having absorbed what I have seen here, looked a little at Mercurial,
read a little on the webs of Fossil and Bazaar I start to think there
is great merit in all this VCS stuff for other types of projects.
At work my projects contain very little coding (some Python, some
matlab/scilab perhaps) but a fair amount of CAD/CAE, written
reports, presentations (OpenOffice and that other Office),
spread sheets etc etc. A mixture of ascii-files and various
proprietary formats most of which is stored in binary form.
Some of the CAE-work generate pretty big files stored
in dynamically created subdirectories.
Our computer environment is mostly based on Vista and Suse Linux
and I still have a SUN Solaris machine in my office but probably
not for long.
Given this type of scenario, what VCS tools should I consider?
Still the Mercurial/Git/Bazaar/Fossil crowd? Any one of those
ruled out and then why?
/Martin
Tim Chase
> You guys are very code focused, which is natural given where we are.
>
> Having absorbed what I have seen here, looked a little at Mercurial,
> read a little on the webs of Fossil and Bazaar I start to think there
> is great merit in all this VCS stuff for other types of projects.
>
> At work my projects contain very little coding (some Python, some
> matlab/scilab perhaps) but a fair amount of CAD/CAE, written
> reports, presentations (OpenOffice and that other Office),
> spread sheets etc etc. A mixture of ascii-files and various
> proprietary formats most of which is stored in binary form.
> Some of the CAE-work generate pretty big files stored
> in dynamically created subdirectories.
For non-text blobs, it takes a little bit of insight to get the
most out of them. For OpenDocument (Open/Libre Office
documents), they're zipped files containing text/XML which can be
diff'ed with more meaning. Usually there are custom filters for
git[1], Mercurial[2] and Bazaar[3] which will unpack the zipped
file contents before committing and give you more sensible diffs.
Likewise, for images (gif/jpg/tiff/raw/etc), there are
particular image-diff programs which make it easier to tell what
happened, as the textual diff of binary files is pretty useless.
However some images (such as .svg files) are XML/text inside,
and diff pretty nicely without extra effort.
I can't speak to CAD/CAE, but it would have to be addressed on a
per-format basis in your given VCS. That said, you *can* store
the binary blobs in each, it's just not as useful without
meaningful comparisons.
-tkc
[1]
http://kerneltrap.org/mailarchive/git/2008/9/15/3305014
[2]
http://mercurial.selenic.com/wiki/HandlingOpenDocumentFiles
Ben Finney
> No need to use VCS at the very beginning of a project. You can easily
> wait until you've written 10 or 20 lines of code :-)
+1 QOTW
> > Should I bother to try a VCS?
>
> Absolutely. Even if you don't need it for a small one-person project,
> it's a good habit to get into.
Yes. Learn to use each of the top-tier VCS options: Bazaar, Git,
Mercurial. Learn to use one of them well (my choice is Bazaar, as
explored elsewhere in this thread).
--
\ “Whenever you read a good book, it's like the author is right |
`\ there, in the room talking to you, which is why I don't like to |
_o__) read good books.” —Jack Handey |
Ben Finney
Shawn Milochik
I personally use git and love it. Most open-source people seem to use
one or the other of the two. They're pretty similar in most ways.
Look at the big two sites for open-source repositories -- github and
bitbucket. One's git, the other Mercurial. I don't think you can go
wrong picking either one.
Dietmar Schwertberger
> Look at the big two sites for open-source repositories -- github and
> bitbucket. One's git, the other Mercurial. I don't think you can go
> wrong picking either one.
Can any of those be used from Python as a library, i.e. something like
import Hg
r = Hg.open(path)
When I had a look at Mercurial, which is implemented in Python,
it was implemented in a way that I could not do that. It was implemented
as rather monolithic program which could be used from os.system(...)
only.
With a good API, I could easily have integrated it into my development
flow. I have a codebase which is shared between different projects and
there are many small changes on many different PCs.
In theory a distributed VCS is good at supporting that, but in practice
I went back to my lightweight synchronization scripts and file storage
again. With the API, I could have best of both worlds.
Regards,
Dietmar
Martin Schöön
/Martin
Jason Earl
You should take a look at Bazaar. I found it fairly easy to use bzrlib
from my own Python scripts.
http://people.canonical.com/~mwh/bzrlibapi/
Jason
Ben Finney
> Am 01.05.2011 02:47, schrieb Shawn Milochik:
> > Look at the big two sites for open-source repositories -- github and
> > bitbucket.
Note that there are three: Launchpad (backed by Bazaar) is the other
“big site” for free-software project hosting.
> Can any of those be used from Python as a library, i.e. something like
> import Hg
> r = Hg.open(path)
I haven't used it, but Launchpad (the Canonical project hosting which
uses Bazaar for the VCS) is of course well-supported in the Bazaar
libraries. Access to the hosting site is eminently programmable with a
good API, by all accounts.
--
\ “It is seldom that liberty of any kind is lost all at once.” |
`\ —David Hume |
_o__) |
Ben Finney
David Boddie
> Am 01.05.2011 02:47, schrieb Shawn Milochik:
>> Look at the big two sites for open-source repositories -- github and
>> bitbucket. One's git, the other Mercurial. I don't think you can go
>> wrong picking either one.
>
> Can any of those be used from Python as a library, i.e. something like
> import Hg
> r = Hg.open(path)
>
> When I had a look at Mercurial, which is implemented in Python,
> it was implemented in a way that I could not do that. It was implemented
> as rather monolithic program which could be used from os.system(...)
> only.
After noting the warnings it contains, see the following page for a
description of the Python API for Mercurial:
http://mercurial.selenic.com/wiki/MercurialApi
Git also has a Python API, which is fairly reasonable to use, though a bit
different to the Mercurial one:
http://www.samba.org/~jelmer/dulwich/
I've used both with some success.
David
Paul Rubin
>> > bitbucket.
> Note that there are three: Launchpad (backed by Bazaar) is the other
> “big site” for free-software project hosting.
There is also patch-tag.com (using darcs) though it is smaller.
rusi
> > A lone developer using such a VCS reaps the benefits of this by getting
> > good merging support.
>
> While we're on the topic, when should a lone developer bother to start
> using a VCS? At what point in the complexity of a project (say a hobby
> project, but > a somewhat seriousish one, around ~5-9k LOC) is the added
> complexity of bringing a VCS into it worth it?
When you hit your first bug?
Ok seriously, when you hit your first serious bug maybe?
I am a bit surprised that no one has mentioned rcs so far
Not an option if you are not on a *ix system and not something I am
specifically recommending.
[I grew up on rcs 15 years ago but not used it much of late]
You may want to look at rcs if you are in the space where you want:
-- something better than tarballs
-- no pretensions beyond single-user, single-machine, (almost)single-
file usage (ie small scale)
-- something that integrates nicely with emacs
Ben Finney
> You may want to look at rcs if you are in the space where you want:
> -- something better than tarballs
> -- no pretensions beyond single-user, single-machine, (almost)single-
> file usage (ie small scale)
> -- something that integrates nicely with emacs
I might have agreed ten years ago; compared to CVS or Subversion, RCS is
simpler to use and set up and had lower workflow overhead.
But today, Bazaar or Mercurial fill that role just as well: quick simple
set up, good tool support (yes, even in Emacs using VC mode), and easy
to use for easy things.
I really don't see any benefit to using RCS for even a lone hacker
tracking files; Bazaar or Mercurial fill that role just as well, and
continue to work well as your needs grow.
--
\ “Philosophy is questions that may never be answered. Religion |
`\ is answers that may never be questioned.” —anonymous |
_o__) |
Ben Finney
rusi
> rusi <rustompm...@gmail.com> writes:
> > You may want to look at rcs if you are in the space where you want:
> > -- something better than tarballs
> > -- no pretensions beyond single-user, single-machine, (almost)single-
> > file usage (ie small scale)
> > -- something that integrates nicely with emacs
>
> I might have agreed ten years ago; compared to CVS or Subversion, RCS is
> simpler to use and set up and had lower workflow overhead.
>
> But today, Bazaar or Mercurial fill that role just as well: quick simple
> set up, good tool support (yes, even in Emacs using VC mode), and easy
> to use for easy things.
>
> I really don't see any benefit to using RCS for even a lone hacker
> tracking files; Bazaar or Mercurial fill that role just as well, and
> continue to work well as your needs grow.
In a word: single files.
If you have a directory with a number of short unrelated scripts --
python, shell etc --
the philosophy: vcs-manages-projects-not-files is a nuisance not a
help.
And which is why things like zit http://git.oblomov.eu/zit have
arisen: the need to go back from bzr/git/hg to (something like) rcs
Algis Kabaila
> rusi <rusto...@gmail.com> writes:
> > You may want to look at rcs if you are in the space where
>
> quick simple set up, good tool support (yes, even in Emacs
> using VC mode), and easy to use for easy things.
>
Actually, Bazaar is more convenient than rcs for a single user,
as the repository can be the working directory (with a "hidden"
.bzr directory that stores diffs).
I had to use git, too, because some projects use git for their
version control (viz PySide, Nokia's tool to replace PyQt). IMHO
there is not much to pick between git and Bazaar and hg is also
rather similar. The remaining doubts are betwwed the
Distributed Version Control and the more traditional Subversion,
which is also quite nice, even for a single user.
OldAl.
--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
rusi
>
> Actually, Bazaar is more convenient than rcs for a single user,
> as the repository can be the working directory (with a "hidden"
> .bzr directory that stores diffs).
Dont exactly understand...
Is it that you want it specifically hidden?
Otherwise rcs will look inside an RCS directory just as bzr will
with .bzr git will with .git and so on.
Algis Kabaila
Sorry for not being clear - "ls" will not show directories that
start with "." - in that sense these directories are "hidden".
They are not really really hidden, as "ls -l" will show them.
They simply are not in the way and keep the progressive versions
of the program (in form of diffs).
Does that make better sense?.
--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
jacek2v
> On Monday 02 May 2011 17:19:57 rusi wrote:
>
> > On May 2, 12:08 pm, Algis Kabaila <akaba...@pcug.org.au>
> wrote:
> > > Actually, Bazaar is more convenient than rcs for a single
> > > user, as the repository can be the working directory (with
> > > a "hidden" .bzr directory that stores diffs).
>
> > Dont exactly understand...
> > Is it that you want it specifically hidden?
> > Otherwise rcs will look inside an RCS directory just as bzr
> > will with .bzr git will with .git and so on.
>
> Sorry for not being clear - "ls" will not show directories that
> start with "." - in that sense these directories are "hidden".
> They are not really really hidden, as "ls -l" will show them.
> They simply are not in the way and keep the progressive versions
> of the program (in form of diffs).
"ls -l will not show directories that start with ".".
"ls -a" will.
Regards
Jacek
Algis Kabaila
Thanks - you are right - pardon my absent mindedness.
Dietmar Schwertberger
> After noting the warnings it contains, see the following page for a
> description of the Python API for Mercurial:
>
> http://mercurial.selenic.com/wiki/MercurialApi
from doing so (and usage of CLI is recommended instead of using the
API).
I had a look at this page in 2009 and came to the conclusion that it's
no good idea to use Mercurial as library. Seems that this still holds
true.
> Git also has a Python API, which is fairly reasonable to use, though a bit
> different to the Mercurial one:
>
> http://www.samba.org/~jelmer/dulwich/
That looks more promising to me.
I think I will try this and Bazaar to find which fits my needs better.
Regards,
Dietmar
Anssi Saari
> I am a bit surprised that no one has mentioned rcs so far
> Not an option if you are not on a *ix system and not something I am
> specifically recommending.
I actually use rcs in Windows. Needs a little setup, but works great,
from Emacs VC-mode too.
jacek2v
You're welcome :)
rusi
Where do you get it?
[What google is showing seems to be about 10-15 years old]
Anssi Saari
>> I actually use rcs in Windows. Needs a little setup, but works great,
>> from Emacs VC-mode too.
>
> Where do you get it?
> [What google is showing seems to be about 10-15 years old]
As far as I know, RCS hasn't been updated since 5.7 which is about 10
years old now. Linux distributions also package the same version. I
use the stuff from rcs57pc1.zip, at ftp://ftp.cs.purdue.edu/pub/RCS/
The package includes also comparison tools cmp, diff, diff3, sdiff as
win32 versions. I suppose one would need to recompile if 64-bit
versions were needed.
The setup I mentioned was just setting RCSINIT to -x,v although I
don't remember now why I needed that.
buck
cd /my/working/dir
hg init
hg add myscript.py
hg ci -m 'added myscript'
It's that simple, and now hyou can go back if you make a terrible mistake, and you can post it to bitbucket and share with the world if you like, almost as easily.
--Buck
buck
http://www.python.org/dev/peps/pep-0374/
There is a tremendous amount of detail there. In summary, hg and git are both very good, and essentially equal in features. The only salient difference is that hg is implemented in python, so they went with that. I did the same, and I'm quite happy. It's basically svn with the shiny new distributed features added.
buck
Jonathan Hartley
> I appreciate any advice or guidance anyone has to offer.
The 'Python Project HOWTO' gives good advice in terms of setting up a
new project, what files and directories to create, what to put in
version control, etc:
http://infinitemonkeycorps.net/docs/pph/
Also, where I work we have tried many IDEs, but happily and
productively use GVim and very little else, so don't feel you *have*
to use an IDE.
Best regards,
Jonathan Hartley
Tim Golden
> On Apr 26, 3:39 pm, snorble<snor...@hotmail.com> wrote:
>> I appreciate any advice or guidance anyone has to offer.
>
> The 'Python Project HOWTO' gives good advice in terms of setting up a
> new project, what files and directories to create, what to put in
> version control, etc:
>
> http://infinitemonkeycorps.net/docs/pph/
I'd forgotten about that. Great resource! Thanks for reminding me...
TJG
rusi
Thanks for that link.
There is one question in this regard that is not covered: package-use
Of course this http://infinitemonkeycorps.net/docs/pph/#id10 is there.
But I am talking of setting up one's python environment.
For example on a linux box how to best optimize using the native
package manager (eg apt/rpm) along with packages from pypi. And when
one needs to run with multiple pythons how to use virtualenv etc
rusi
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
>
> My current practices:
>
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file. Then I hack
> away, adding features in a semi-random order. Then I get busy with
> other things. Maybe one week I spend 20 hours on development. The next
> week, no time on development. A few weeks later when I have some time,
> I'm excited to get back to making progress, only to find that I have
> to spend 30-60 minutes figuring out where I left off. The code is
> usually out of sync with todo.txt. I see people who release new
> versions and bug fixes, so I sometimes will create a new directory and
> continue working from that copy, because it seems like the thing to
> do. But if I ever made something worth releasing, and got a request
> like, "I have problems with the 2.0 version. Can you send me the old
> 1.1 version?" I'd be like, "uhhh... let me hunt through my files by
> hand and get back to you in a month". I'm thinking I can do a lot
> better than this.
>
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly. I think having some organization to all of this
> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.
>
> I really like the idea of having a list of features, and tackling
> those features one at a time. I read about people who do this, and
> each new features gets a new minor version number. It sounds very
> organized and clean. But I'm not really sure of the best way to
> achieve this. Mainly I think I just need some recommendations to help
> create a good mental map of what needs to happen, and mapping jargon
> to concepts. Like, "each feature gets its own directory". Or with a
> version control tool, I don't know if a feature maps to a branch, or a
> commit?
>
> I appreciate any advice or guidance anyone has to offer.
Recently saw this: [Disclaimer: Not tried]
http://labs.creativecommons.org/2010/11/10/bridging-public-bugtrackers-and-local-tasklists/
Roy Smith
<58a6bb1b-a98e-4c4a...@r35g2000prj.googlegroups.com>,
snorble <sno...@hotmail.com> wrote:
> [standard tale of chaotic software development elided]
>
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly.
None of this has anything to do with python. It's all standard software
engineering stuff that's the same with any language or technology.
Bug trackers are essential for large projects. For a one-man project,
it's probably more effort than it's worth. For the project I'm on now
(4 developers co-located with the customer), we're using a shared google
docs spreadsheet for bug tracking. It's free, low-overhead, and works
well enough. For a single person, even that may be more than you need.
On the other hand version control is essential from day zero, even on a
one-man project. There's plenty of perfectly good, free, systems out
there. The obvious choices are hg, git, and bzr. Pick one and use it.
The nice thing about them all is there's no lock-in. If you decide you
don't like the one you're using, you can easily convert your entire code
repository to any of the others without losing anything.
> I really like the idea of having a list of features, and tackling
> those features one at a time.
Yup, that's the core concept of all the agile development processes that
are all the rage these days. Sometimes called "release early and often".
> I read about people who do this, and
> each new features gets a new minor version number.
For the project I'm on, we don't even bother with version numbers. We
have a main branch which we (try to) keep stable and shippable at all
times, and push that to production whenever we've completed a feature
(or bug fix) that the customer needs. I see we're currently running:
9be3fc6a0e01cf128f63d1af2b19c180fb4eaacb (tip)
Version numbers make more sense with a traditional ("waterfall") type
process, where you design a bunch of stuff, write the code, go through a
testing and bug-fixing cycle, and the finally push it out the door.
> I think I just need some recommendations to help
> create a good mental map of what needs to happen, and mapping jargon
> to concepts. Like, "each feature gets its own directory". Or with a
> version control tool, I don't know if a feature maps to a branch, or a
> commit?
Well, start from the premise that you have a main branch which is always
shippable. That means the code runs and passes all the tests after
every single commit to that branch.
Now, when you need to make a change (add a feature or fix a bug), ask
yourself if the change is small enough that you can do all the work
required in one day. If so, then doing it in a single commit on your
main branch may make sense. If not, then spin up a development branch,
do the work there, and when you're satisfied it's shippable, merge it
onto your main branch.
rusi
think of a name myself.
There is this whole area of python that may be called the non-
programming side of programming:
Is there some central site where all such is put up?
What if any should such a bundle of things be called?
-------------------------------------------------
| Area | Tool(s) |
|------------------+------------------------|
| packaging | distutils, setuptools, |
| | distutils2, distribute |
| | Native tools (eg apt) |
| versioning | hg, git, bzr |
| multiple pythons | virtualenv |
| ?? | tox |
| testing | unittest, nose, pytest |
| build | scons, make... |
| deployment | fabric |
------------------------------
* Primary Development tools/aids
1. Help
2. Completion ('intellisense')
3. Tags (Jumping)
4. Refactoring
5. Integration with 'non-programming' above (eg VCSes, packagers
etc)
* Other Development Tools
- Debugger
- Profiler
- Heap Profiler
- Coverage
Terry Reedy
> Sorry for a silly subject change: A better one will be welcome -- cant
> think of a name myself.
Associated tools. I might separate them into development tools (up to
the production of python.exe) and usage tools (everything thereafter).
On Windows, this is a pretty clean separation. On Linux, less so since
users sometimes build their own binaries and therefore use some of the
development tools.
Assuming that there is not one already, this could be the beginning of a
useful overview wiki page with links to existing pages on the specific
topics ('areas') listed below.
> There is this whole area of python that may be called the non-
> programming side of programming:
>
> Is there some central site where all such is put up?
> What if any should such a bundle of things be called?
>
> -------------------------------------------------
>
> | Area | Tool(s) |
> |------------------+------------------------|
> | packaging | distutils, setuptools, |
> | | distutils2, distribute |
> | | Native tools (eg apt) |
> | versioning | hg, git, bzr |
> | multiple pythons | virtualenv |
> | ?? | tox |
> | testing | unittest, nose, pytest |
> | build | scons, make... |
> | deployment | fabric |
>
> ------------------------------
I would reorder this list in the typical order used, starting with editors.
> * Primary Development tools/aids
>
> 1. Help
> 2. Completion ('intellisense')
> 3. Tags (Jumping)
> 4. Refactoring
> 5. Integration with 'non-programming' above (eg VCSes, packagers
> etc)
>
> * Other Development Tools
> - Debugger
> - Profiler
> - Heap Profiler
> - Coverage
--
Terry Jan Reedy
Steven D'Aprano
> Sorry for a silly subject change: A better one will be welcome -- cant
> think of a name myself.
>
> There is this whole area of python that may be called the non-
> programming side of programming:
>
> Is there some central site where all such is put up? What if any should
> such a bundle of things be called?
Documentation.
Check the Python wiki.
--
Steven
rusi
> On 5/10/2011 12:41 PM, rusi wrote:
>
> > Sorry for a silly subject change: A better one will be welcome -- cant
> > think of a name myself.
>
> Associated tools. I might separate them into development tools (up to
> the production of python.exe) and usage tools (everything thereafter).
> On Windows, this is a pretty clean separation. On Linux, less so since
> users sometimes build their own binaries and therefore use some of the
> development tools.
Can you elaborate? I dont understand
Some more 'areas':
1. Which python 'form' does one use?
At the least python vs pythonw on windows.
But more generally scripting vs REPL. In REPL python vs ipython
Note 1. I am often unnerved by how even experienced python programmers
think that the only way to 'do' python is like C -- write a main, not
appreciating the luxury of an unstructured, exploratory mode that an
REPL makes possible.
Note 2. ruby makes this distinction more obvious by distinguishing the
scripting engine -- ruby -- form the interactive interpreter (REPL) --
irb.
2. Literate Programming: When the primary purpose of the program is
not the program but (some form of) discussion around it
3. Program namespace lookup and structuring: sys.path is the interior
program view but there is also the 'exterior' view -- PYTHONPATH, .pth
files etc.
Finally some thoughts on how to name this list of areas:
a. Software Engineering? : Inasmuch as real program development is
programming + 'something-else' and SE is that 'something else'
b. Python Development Environment? Similar to above
[Cannot say I like these names too much but at least its more specific
than Steven's vanilla 'documentation' :-) ]