Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Periodic Save As

by jonadab (Parson)
on May 16, 2008 at 12:53 UTC ( #686908=note: print w/ replies, xml ) Need Help??


in reply to My preferred version control system is...

Since I'm pretty much the entire IT department myself, there's generally nobody else making edits. So I keep one "production" copy, which I don't edit, and of which I always make a backup copy (usually with zip) before upgrading it. I keep one "development" version, which I edit directly, and which I periodically (when it seems stable) copy over to upgrade the production copy. Plus backups, which I definitely don't edit. So at any given time there's only one (1) copy that may have changes. No differences between multiple development versions means no merging.

Obviously this approach won't work so well for large teams of developers working on the same project simultaneously... but it works for me :-)

My dirty little secret is that there are some projects where I know I'm basically the only user, and in those cases I generally don't bother keeping a separate development version: I just edit the production code directly. This is not a practice I particularly recommend, but out of laziness it's what I sometimes end up doing.

-- 
We're working on a six-year set of freely redistributable Vacation Bible School materials.


Comment on Periodic Save As
Re: Periodic Save As
by GrandFather (Cardinal) on May 18, 2008 at 11:03 UTC

    Actually it's not just large teams that it doesn't work well for. Often it doesn't work well for teams of one either.

    One good reason for using a version control system even when you are the sole developer and user is that it records the change history including meaningful check in comments. That means there is no need to clutter the code with comments that explain the evolutionary steps that brought the code into the current state.

    Even for a single developer having a version control system and making fairly regular check ins provides a nice warm comfortable feeling when you are about to wreck havoc in the code, or have just made a bigger mess than intended.


    Perl is environmentally friendly - it saves trees
      I've got to agree here, although when you are the sole developer you don't usually need to worry about things like branches. I even keep my agenda and similar files in a revision control system, and I have gone back to view old appointments. As an added bonus, it's a nice way to keep everything synced between the different desktops I use and the server with the repository gives off-site backup without me having to think about it.

      I can't imagine not wanting to use revision control for code, especially when it takes so little effort to use a minimal subset of features properly.

        Branching is simply a necessary evil when distributing releases to a user-base. This is because you will want to work on the next major release while still being able to produce patches for past releases. It is likely that you will want to merge your patch into the next release at some point, but that is a subsequent task to developing the patch in the first place.


        Wait! This isn't a Parachute, this is a Backpack!
      One good reason for using a version control system even when you are the sole developer and user is that it records the change history including meaningful check in comments. That means there is no need to clutter the code with comments that explain the evolutionary steps that brought the code into the current state.

      You know, I always assumed that would be the case, and then I was in a situation where I was doing some CVS check-ins on an open-source project, and at one point one of the lead developers felt the need to make me aware of the fact that I should be duplicating my check-in comments in the changelogs, manually, because the version-control system did not automatically keep track of them in any accessible way.

      Well, if I'm going to keep changelogs anyway (and yeah, I do do that), then what on earth do I need version control check-in comments for?

      -- 
      We're working on a six-year set of freely redistributable Vacation Bible School materials.
        lead developers felt the need to make me aware of the fact that I should be duplicating my check-in comments in the changelogs, manually, because the version-control system did not automatically keep track of them in any accessible way.

        http://search.cpan.org/dist/CVSUtils-1.01/bin/cvs2cl

      I have to agree here. I started picking up git recently on my (sad, weak, toy) programming projects, and I have to say, being able to look back at what I did two or three revisions back is nice.

      Also, it just seems simpler to use branching for features I'm experimenting with than to copy the whole project.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://686908]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (14)
As of 2014-08-22 12:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (156 votes), past polls