use make and version control system for every project?

Discussion in 'Python' started by AK, Oct 6, 2003.

  1. AK

    AK Guest

    Hi, I recently read an advice here that one should try to use make and
    version control system even if you're the only one working on the
    program. Is that a good advice? How many of you do that?

    Thanks,

    -AK
     
    AK, Oct 6, 2003
    #1
    1. Advertising

  2. AK

    Carl Banks Guest

    AK wrote:
    > Hi, I recently read an advice here that one should try to use make and
    > version control system even if you're the only one working on the
    > program. Is that a good advice? How many of you do that?



    Personally, I use make on every single one of my projects. I even use
    make to run setup.py in my pure Python packages. (Cause it's just
    easier to 'type make install' than 'python setup.py install--home=~'.)
    It's not necessary, but it can save a lot of work and keep everything
    up-to-date.

    Version control, it depends. I've used CVS for some personal projects
    before, and can't say I've ever found it useful, and it's definitely a
    pain to keep things up-to-date. I recommend, for personal projects,
    not bothering with version control at least until the project is
    fairly stable.

    But if you don't use version control, be sure to make frequent backups
    (and store the backups on another medium; hard disks crash; it
    happened to me).


    my-2-cents-ly yr's,

    --
    CARL BANKS http://www.aerojockey.com/software

    As the newest Lady Turnpot descended into the kitchen wrapped only in
    her celery-green dressing gown, her creamy bosom rising and falling
    like a temperamental souffle, her tart mouth pursed in distaste, the
    sous-chef whispered to the scullery boy, "I don't know what to make of
    her."
    --Laurel Fortuner, Montendre, France
    1992 Bulwer-Lytton Fiction Contest Winner
     
    Carl Banks, Oct 6, 2003
    #2
    1. Advertising

  3. AK wrote:

    > Hi, I recently read an advice here that one should try to use make and
    > version control system even if you're the only one working on the
    > program. Is that a good advice? How many of you do that?


    Yes, and yes. All my Web sites and programs are built with make, even
    my resume (of which a few variations are built from templates and then
    each is automatically converted to a bunch of formats).

    Using source control, even for your solitary projects, is always
    advisable: you get a little touch of automatic backups (particularly if
    your source control server is on a different machine), as well as the
    ability to work on different branches simultaneously and have
    authoritative information on precisely what you did to your software and
    when.

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Every path has its puddle.
    \__/ (an English proverb)
     
    Erik Max Francis, Oct 6, 2003
    #3
  4. AK

    Peter Hansen Guest

    AK wrote:
    >
    > Hi, I recently read an advice here that one should try to use make and
    > version control system even if you're the only one working on the
    > program. Is that a good advice? How many of you do that?


    I don't use make with Python, but I use it with anything
    compiled, as with embedded development.

    I *always* use CVS at this point, and I deeply regret the years that
    I spent not using it and the many varied ways in which I made negative
    progress because of that (lost files, incompatibilities that could not
    be resolved between various versions of things, inability to identify
    exactly when and why a given thing was done, etc).

    I _strongly_ recommend learning to use CVS, or *any equally simple
    version control system*, even for personal projects, so that it becomes
    second nature early on and you never find yourself without it.

    -Peter
     
    Peter Hansen, Oct 6, 2003
    #4
  5. AK

    Roy Smith Guest

    Carl Banks <> wrote:
    > Version control, it depends. I've used CVS for some personal projects
    > before, and can't say I've ever found it useful, and it's definitely a
    > pain to keep things up-to-date. I recommend, for personal projects,
    > not bothering with version control at least until the project is
    > fairly stable.


    I suppose this is a personal preference kind of thing, but I use
    revision control (CVS or RCS mostly, Clearcase when they hold a gun to
    my head) for everything, from the very beginning. Source code,
    documents, test notes, project plans, it all goes under revision
    control. I check stuff in often and early.

    I do that even if it's just something I'm working on for myself. It
    might be a little silly, but that's what I've found works well for me.
    For any project with more than one person working on it, however, you
    would be insane not to use some sort of revision control system.

    I find it gives me a lot of value. There's the built-in backups
    (although, the CVS repository itself needs to be backed up). There's
    the running commentary of the checkin messages (I'm pretty anal about
    trying to keep a good checkin log). There's the ability to branch a
    file to explore some experimental changes. If you don't like CVS, there
    are plenty of other revision control systems to look at, ranging from
    free to mega-bucks.

    I don't see a whole lot of value for make in a python project. I use it
    myself mostly to drive unit test suites, but that's more force of habit
    than anything else. I should probably replace those Makefiles with
    python scripts :) If you don't like make (and there's plenty not to
    like), there are other, newer, systems around like Ant and Jam that are
    worth looking at.

    Of course, none of this really has much to do with Python. These are
    all generic software engineering issues.
     
    Roy Smith, Oct 6, 2003
    #5
  6. AK

    Ben Finney Guest

    On Mon, 06 Oct 2003 01:40:38 GMT, AK wrote:
    > Hi, I recently read an advice here that one should try to use make and
    > version control system even if you're the only one working on the
    > program. Is that a good advice? How many of you do that?


    Definitely, to both questions.

    The 'make' tool allows automation of project building and other tasks,
    which is immensely useful whether you work alone or not.

    Revision control alows you to checkpoint particular revisions of the
    project (or parts thereof) in a way much more transparent than copying
    files around manually.

    And you never know which lone-gun projects will require additional help,
    so placing all of them under revision control and automated build will
    allow you to bring people in much more easily.

    --
    \ "Better not take a dog on the space shuttle, because if he |
    `\ sticks his head out when you're coming home his face might burn |
    _o__) up." -- Jack Handey |
    Ben Finney <http://bignose.squidly.org/>
     
    Ben Finney, Oct 6, 2003
    #6
  7. AK

    Carl Banks Guest

    Roy Smith wrote:
    > Carl Banks <> wrote:
    >> Version control, it depends. I've used CVS for some personal projects
    >> before, and can't say I've ever found it useful, and it's definitely a
    >> pain to keep things up-to-date. I recommend, for personal projects,
    >> not bothering with version control at least until the project is
    >> fairly stable.

    >
    > I suppose this is a personal preference kind of thing, but I use
    > revision control (CVS or RCS mostly, Clearcase when they hold a gun to
    > my head) for everything, from the very beginning. Source code,
    > documents, test notes, project plans, it all goes under revision
    > control.


    Best yet, the OP should probably try it and see if it works for him.

    I recommended not bothering early on because I tend to move files
    around quite a bit early on (a major pain in CVS), and I suspect I'm
    not the only person to do that. But if he's the type of person whose
    projects are "fairly stable" in the very beginning, by all means, he
    should CVS away.

    [snip]
    > There's the running commentary of the checkin messages (I'm pretty
    > anal about trying to keep a good checkin log).


    Incidentally, this is probably greatest strength of version control
    relative to frequent backups (for personal projects, of course). It's
    also a feature I've found extremely little use for. I mean, it sounds
    cool to be able to go back and see exactly when you made a certain
    change, but is that really useful in practice?

    I'm sorry, but my pragmatic mind tells me it's all wasted effort, a
    lot of work for little benefit. Frequent backups do well enough for
    me, with far less effort, so it's what I've been moving towards.

    But whatever works for you. And, of course, the OP should try it and
    decide if it works for him.


    --
    CARL BANKS http://www.aerojockey.com/software

    As the newest Lady Turnpot descended into the kitchen wrapped only in
    her celery-green dressing gown, her creamy bosom rising and falling
    like a temperamental souffle, her tart mouth pursed in distaste, the
    sous-chef whispered to the scullery boy, "I don't know what to make of
    her."
    --Laurel Fortuner, Montendre, France
    1992 Bulwer-Lytton Fiction Contest Winner
     
    Carl Banks, Oct 6, 2003
    #7
  8. AK

    Ben Finney Guest

    On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:
    > I recommended not bothering early on because I tend to move files
    > around quite a bit early on (a major pain in CVS), and I suspect I'm
    > not the only person to do that.


    That's a flaw of CVS, not of revision control. Other revision control
    systems (Arch, Subversion, even RCS) don't suffer from this flaw; use
    any of those to have *no* excuse not to use revision control from the
    project's inception.

    > Incidentally, this is probably greatest strength of version control
    > relative to frequent backups (for personal projects, of course). It's
    > also a feature I've found extremely little use for. I mean, it sounds
    > cool to be able to go back and see exactly when you made a certain
    > change, but is that really useful in practice?


    It's more than cool.

    A change history is vital on a fast-changing project; you can see when a
    particular feature went in, when a bug was fixed, when a structural
    change was made, etc.

    A change history is vital in multi-developer projects (though that's not
    what the OP asked about) to supplement fallible human memory.

    A change history is required by many free software licenses (the GPL
    being one) when you change another's work.

    Sound useful enough?

    --
    \ "Last year I went fishing with Salvador Dali. He was using a |
    `\ dotted line. He caught every other fish." -- Steven Wright |
    _o__) |
    Ben Finney <http://bignose.squidly.org/>
     
    Ben Finney, Oct 6, 2003
    #8
  9. AK

    Carl Banks Guest

    Ben Finney wrote:
    > On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:
    >> I recommended not bothering early on because I tend to move files
    >> around quite a bit early on (a major pain in CVS), and I suspect I'm
    >> not the only person to do that.

    >
    > That's a flaw of CVS, not of revision control. Other revision control
    > systems (Arch, Subversion, even RCS) don't suffer from this flaw; use
    > any of those to have *no* excuse not to use revision control from the
    > project's inception.


    Well, I've never used Arch or Subversion, so I can't evaluate them.
    I'd expect too much moving files around to be a headache in general
    (even if the system used is a lot better than CVS), but maybe those
    other systems make it effortless. (shrug).


    >> Incidentally, this is probably greatest strength of version control
    >> relative to frequent backups (for personal projects, of course). It's
    >> also a feature I've found extremely little use for. I mean, it sounds
    >> cool to be able to go back and see exactly when you made a certain
    >> change, but is that really useful in practice?

    >
    > It's more than cool.
    >
    > A change history is vital on a fast-changing project; you can see when a
    > particular feature went in, when a bug was fixed, when a structural
    > change was made, etc.


    Why is that important? How often do you really need to know when a
    bug was fixed, for example? (I'm serious. I've never needed to know
    these things. Do other people really use these features for personal
    projects? And if they do, is it really that often?)


    > A change history is vital in multi-developer projects (though that's not
    > what the OP asked about) to supplement fallible human memory.


    It's not what I was talking about, either. Of course, version control
    is needed if there's more than a few people working on something.


    > A change history is required by many free software licenses (the GPL
    > being one) when you change another's work.


    Well, that's certainly a good enough reason to use it, when such a
    situation occurs.


    > Sound useful enough?


    I don't know. Reasons B and C don't apply to most personal projects,
    and I'm not convinced of the usefulness of Reason A.


    --
    CARL BANKS http://www.aerojockey.com/software

    As the newest Lady Turnpot descended into the kitchen wrapped only in
    her celery-green dressing gown, her creamy bosom rising and falling
    like a temperamental souffle, her tart mouth pursed in distaste, the
    sous-chef whispered to the scullery boy, "I don't know what to make of
    her."
    --Laurel Fortuner, Montendre, France
    1992 Bulwer-Lytton Fiction Contest Winner
     
    Carl Banks, Oct 6, 2003
    #9
  10. AK

    David Mertz Guest

    |Ben Finney wrote:
    |> A change history is vital on a fast-changing project; you can see when a
    |> particular feature went in, when a bug was fixed, when a structural
    |> change was made, etc.

    Carl Banks <> wrote previously:
    |Why is that important? How often do you really need to know when a
    |bug was fixed, for example? (I'm serious. I've never needed to know
    |these things. Do other people really use these features for personal
    |projects? And if they do, is it really that often?)

    I've been maintaining my package Gnosis Utilities for a couple years
    now. It's a real public project--used by a fair number of people, and
    with contributions from a couple dozen. Not a -huge- project, but more
    than trivial. A bit less than a meg of pure Python and textual
    documentation (I forget now what good LOC counters are, I know I tried a
    couple in the past).

    I've never gotten around to using any sort of version control system.
    Well, unless you count keeping archives of all the old releases on my
    web site. Of course, I've also never really given anyone else "check in
    priviledges" either (there are some contributors I trust quite a lot--
    but even there, I still eyeball their code, and make sure I understand
    what it does, why it does it, and that I like the comments and variable
    names).

    In those couple years, I think I have wondered about exactly when a
    particular fix went in exactly ONCE. Finding the answer was more
    work than it should have been, I suppose. I had to glance through a
    couple old versions. Actually, even then it was more about trying to
    remember some old API details for backward compatibility, not really a
    date question.

    YMMV, of course. And I certainly think something larger and/or more
    corporate should use version control. But I'm with Carl in not really
    getting it for small semi-personal projects.

    Yours, David...

    --
    mertz@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
    gnosis _/_/ Postmodern Enterprises \_\_
    ..cx _/_/ \_\_ d o
    _/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e
     
    David Mertz, Oct 6, 2003
    #10
  11. AK

    Tim Churches Guest

    On Mon, 2003-10-06 at 17:43, David Mertz wrote:
    > YMMV, of course. And I certainly think something larger and/or more
    > corporate should use version control. But I'm with Carl in not really
    > getting it for small semi-personal projects.


    I would have said so too, but 6 months ago I had occasion to work
    jointly on some Python code (about 6000 lines worth) with a programmer
    working under contract to my employer. He was located in Melbourne
    (Australia), I was (at the time) in Manila (Philippines). Code was
    stored on a CVS server in Melbourne, which I accessed via a dial-up
    Internet connection from my ancient Linux laptop. I was doubtful at
    first, but the whole thing worked a treat over a three week period. At
    times both of us were working on the different parts of the same Python
    module (i.e the same file), and to my amazement CVS merged the changes
    made by both of us with very few conflicts and little need for revision
    of the merged code.

    The biggest source of difficulty was my (continuing) insistence on using
    tab characters for Python indenting, whereas my co-programmer preferred
    his tab key to introduce a string of 4 spaces...

    --

    Tim C

    PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
    or at http://members.optushome.com.au/tchur/pubkey.asc
    Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.7 (GNU/Linux)

    iD8DBQA/gSuIeJFGqer5k9ARAuHKAKDgIHLPLqBfrq3ZwyG3IrSP1Fse7ACggG0c
    1LS9aZQqlYxJHB4+R5xABdc=
    =vm9r
    -----END PGP SIGNATURE-----
     
    Tim Churches, Oct 6, 2003
    #11
  12. AK

    Max M Guest

    Carl Banks wrote:

    >>A change history is vital on a fast-changing project; you can see when a
    >>particular feature went in, when a bug was fixed, when a structural
    >>change was made, etc.

    >
    > Why is that important? How often do you really need to know when a
    > bug was fixed, for example? (I'm serious. I've never needed to know
    > these things. Do other people really use these features for personal
    > projects? And if they do, is it really that often?)



    There is a difference in personal projects, and projetcs done by an
    individual. If you just write something for your own use it might not
    matter much.

    But if you write something for customers, or something that other people
    use, it is a good idea to be able to tell the customer what changes are
    made in the latest version they have received.

    It can also be an advantage when billing.

    regards Max M
     
    Max M, Oct 6, 2003
    #12
  13. AK

    sashan Guest

    AK wrote:

    >Hi, I recently read an advice here that one should try to use make and
    >version control system even if you're the only one working on the
    >program. Is that a good advice? How many of you do that?
    >
    > Thanks,
    >
    > -AK
    >
    >

    Ever since I was introduced to revision control I've used it for
    individual projects. I've used/use SourceSafe, Bitkeeper, cvs and
    subversion. I recommend that you use some form of revision control for
    the following reasons:

    1) It's a good habit to get into. If you eventually end up on a team
    you'll use revision control so practicing with an individual project
    isn't going to hurt.
    2) Backups - a revision control system becomes your back up tool.
    3) Difftools - sometimes you have make a change to a file and a few days
    latter a bug apears in your code. With revision control you can do a
    diff between the current file and any previous version to see what
    change introduced the bug.
    4) Tags/Labels - When you're satisfied with the progress of your project
    you can label the repository as say version 1.0. This marks all the
    files in the repository as version 1.0. Then at a later date you can
    easily go back to the source tree as it was when you finished version 1.0.

    I worked for a short time with a company that didn't use revision
    control (and these were people who were meant to have 5 to 10 or so
    years in IT industry experience.) Their source tree was simply put on a
    shared server. The number of developers working on that tree at the same
    time ranged from 1 to 4 so it was manageable, but it still sucked. I
    tried to explain how to use sourcesafe and setup a server to the guy in
    charge of development but I don't think he got it. They were all VB
    programmers so I guess that explains their incompetence.

    Personally I use Bitkeeper for most of my work now. Since I work
    sometimes at home and sometimes at uni it's nice to be able to store my
    code/thesis on a server that I can access from anywhere. It also saves
    me having to maintain backups. I'm also using Subversion for a part-time
    contract I'm working on. I occasionally use cvs since I have a little
    neglected project on sourceforge. I've haven't used sourcesafe in a
    while. I recommend using Bitkeeper or Subversion because they can track
    renames of files. cvs can't and iirc neither can sourcesafe.

    --
    sashan
    http://www.cs.auckland.ac.nz/~sgov008/
     
    sashan, Oct 6, 2003
    #13
  14. AK

    Jorge Godoy Guest

    Peter Hansen <> writes:

    > I _strongly_ recommend learning to use CVS, or *any equally simple
    > version control system*, even for personal projects, so that it becomes
    > second nature early on and you never find yourself without it.


    I second that.

    CVS also solves problems of identifying what is the little thing that
    you changed and made your program stop running the way it should.

    It also makes it easier to backup projects: you only need to backup
    the CVS repository on the server.

    Planning and integrating programs also is easier (no matter if the
    language supports a centralized installation such as Python and Perl
    do or not).


    With regards to make, I believe that distutils would be its
    equivalent in pythonia. It is somewhat unintuitive in some things, but
    is a good tool. And helps generating an installable 'package' with
    your code, making it easier to share it.

    --
    Godoy. <>
     
    Jorge Godoy, Oct 6, 2003
    #14
  15. AK

    Jorge Godoy Guest

    Carl Banks <> writes:

    > Why is that important? How often do you really need to know when a
    > bug was fixed, for example? (I'm serious. I've never needed to know
    > these things. Do other people really use these features for personal
    > projects? And if they do, is it really that often?)


    Maybe your client calls you and says that the program is not working
    as it should and say that he doesn't know the number of his version
    immediately, but he remembers it was installed one or two weeks
    ago... You remember solving such a bug, but when?

    > It's not what I was talking about, either. Of course, version control
    > is needed if there's more than a few people working on something.


    To me, 'few = 0', but to you it might be 'few = 1' or more... This
    varies from group to group too. We had a team that worked synced and
    that could have 5 developers working very fine just by themselves, but
    another team required a version control system for just 2 of
    them...

    Revision control systems are not a substitute for project management
    and meetings.



    --
    Godoy. <>
     
    Jorge Godoy, Oct 6, 2003
    #15
  16. Carl Banks wrote:
    > Ben Finney wrote:
    > > On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:
    > >> I recommended not bothering early on because I tend to move files
    > >> around quite a bit early on (a major pain in CVS), and I suspect I'm
    > >> not the only person to do that.

    > >
    > > That's a flaw of CVS, not of revision control. Other revision control
    > > systems (Arch, Subversion, even RCS) don't suffer from this flaw; use
    > > any of those to have *no* excuse not to use revision control from the
    > > project's inception.

    >
    > Well, I've never used Arch or Subversion, so I can't evaluate them.
    > I'd expect too much moving files around to be a headache in general
    > (even if the system used is a lot better than CVS), but maybe those
    > other systems make it effortless. (shrug).



    JFYI, subversion makes this quite effortless because it basically
    is a transactional filesystem. 'svn mv' will work just like 'mv'
    in unix when you are moving stuff around in your working-copy. Of
    course, you still have to commit 'svn ci' to make the moves
    persistent.

    cheers, holger
     
    Holger Krekel, Oct 6, 2003
    #16
  17. AK

    John J. Lee Guest

    Jorge Godoy <> writes:

    > Peter Hansen <> writes:

    [...]
    > CVS also solves problems of identifying what is the little thing that
    > you changed and made your program stop running the way it should.


    So does diff.

    I tried CVS for personal work and found it more pain that it was
    worth. I can believe other VC systems are sufficiently better to make
    it worthwhile, though (moving directories around).


    [...]
    > With regards to make, I believe that distutils would be its
    > equivalent in pythonia. It is somewhat unintuitive in some things, but


    Not really -- scons is the equivalent.


    John
     
    John J. Lee, Oct 6, 2003
    #17
  18. AK

    Jorge Godoy Guest

    (John J. Lee) writes:

    > So does diff.


    For using diff I'd have to keep several copies os my full
    project. With CVS I just keep one full copy -- the last revision ---
    and diffs to each revision (it's automatic). The space saved is
    substantial for a big sized project.

    > I tried CVS for personal work and found it more pain that it was
    > worth. I can believe other VC systems are sufficiently better to make
    > it worthwhile, though (moving directories around).


    I'm biased towards CVS, I'm sorry.

    On the other hand, I've been hearing great things about subversion. I
    just need to check if there are nice clients to it on Windows too
    (some partners of mine only use Windows...).

    > [...]
    >> With regards to make, I believe that distutils would be its
    >> equivalent in pythonia. It is somewhat unintuitive in some things, but

    >
    > Not really -- scons is the equivalent.


    Hmmm... I should have a look into them. Thanks for the correction.

    --
    Godoy. <>
     
    Jorge Godoy, Oct 6, 2003
    #18
  19. AK

    Roy Smith Guest

    sashan <> wrote:
    > I'm also using Subversion for a part-time contract I'm working on.


    How's that working out? I've been watching the subversion project for
    several years with interest, but so far havn't worked up the courage to
    actually use it for anything.

    I'm mostly happy with CVS, except for a few things. High on the list is
    the inability to move files around, as others have mentioned. I know
    subversion fixes that one. Sounds like an interesting system, but it's
    hard to get a good feel for how solid the thing is from reading the
    release notes. It's hard to abandon an old tool that mostly works well
    without a lot of confidence in the new one.
     
    Roy Smith, Oct 6, 2003
    #19
  20. AK

    anton muhin Guest

    Jorge Godoy wrote:
    > On the other hand, I've been hearing great things about subversion. I
    > just need to check if there are nice clients to it on Windows too
    > (some partners of mine only use Windows...).


    Yes, and they are really nice IMHO.

    regards,
    anton.
     
    anton muhin, Oct 6, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pettersen, Bjorn S
    Replies:
    3
    Views:
    313
    Peter Hansen
    Oct 6, 2003
  2. =?Utf-8?B?SXJ3YW5zeWFo?=
    Replies:
    4
    Views:
    2,485
    =?Utf-8?B?SXJ3YW5zeWFo?=
    Oct 30, 2007
  3. V Green
    Replies:
    0
    Views:
    903
    V Green
    Feb 5, 2008
  4. PA Bear [MS MVP]
    Replies:
    0
    Views:
    1,018
    PA Bear [MS MVP]
    Feb 5, 2008
  5. MowGreen [MVP]
    Replies:
    5
    Views:
    2,061
    PA Bear [MS MVP]
    Feb 9, 2008
Loading...

Share This Page