Periodic Save As

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

Replies are listed 'Best First'.
Re: Periodic Save As by GrandFather (Saint) 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	[reply]
Re^2: Periodic Save As by kudra (Vicar) on May 21, 2008 at 21:40 UTC
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.	[reply]
Re^3: Periodic Save As by gregor42 (Parson) on May 23, 2008 at 13:35 UTC
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!	[reply]
Re^4: Periodic Save As by kudra (Vicar) on May 23, 2008 at 16:54 UTC
Re: Periodic Save As by jonadab (Parson) on May 24, 2008 at 11:04 UTC
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.	[reply]
Re^2: Periodic Save As by Anonymous Monk on May 24, 2008 at 12:09 UTC
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	[reply]
Re^3: Periodic Save As by GrandFather (Saint) on May 25, 2008 at 16:29 UTC
Re^2: Periodic Save As by pobocks (Chaplain) on May 26, 2008 at 02:07 UTC
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.	[reply]


Welcome to the Monastery
	PerlMonks