General: Version Control for IF
Jim Aikin
to be very inadequate. I need to set up a decent system before starting work
on my next game.
Looking around the Web, my first impression is that most version control
systems are WAAAY more than I need as a solo developer. Plus, it looks like
the free ones run only on Unix/Linux systems.
So my question for others in this group is, how do you do it? Copying the
whole source code directory to a new backup file every day? Or is that
enough? Do you incrementally rename source files? Keep a manually written
log of changes? Do you have any software tools that help?
Thanks!
--Jim Aikin
Darren Bane
> My version control and tracking system for my recent project has turned out
> to be very inadequate. I need to set up a decent system before starting work
> on my next game.
>
> Looking around the Web, my first impression is that most version control
> systems are WAAAY more than I need as a solo developer.
That's the caveat with my reply, all my experience has been for
medium to large software development teams, not individual developers.
> Plus, it looks like
> the free ones run only on Unix/Linux systems.
>
> So my question for others in this group is, how do you do it? Copying the
> whole source code directory to a new backup file every day? Or is that
> enough? Do you incrementally rename source files? Keep a manually written
> log of changes?
No, no, no and no.
> Do you have any software tools that help?
Yes. For corporations I would usually recommend Darcs along with a
process emphasising peer review of distributed repositories, or if this
isn't acceptable for pointy-haired-boss type reasons, a second choice
of Subversion with a centralised repository.
But none of this is really relevant to a lone developer. You're better
off going back to the tools that were used 20 years ago (sccs and rcs).
Here's a free Windows version of RCS:
http://www.componentsoftware.com/csrcs/
(I guess you're using Windows, since Unix/Linux aren't acceptable).
--
Darren Bane
vaporware
> My version control and tracking system for my recent project has turned out
> to be very inadequate. I need to set up a decent system before starting work
> on my next game.
>
> Looking around the Web, my first impression is that most version control
> systems are WAAAY more than I need as a solo developer. Plus, it looks like
> the free ones run only on Unix/Linux systems.
There are free CVS programs for Windows:
http://www.tortoisecvs.org/
http://www.wincvs.org/
vw
Jon Rosebaugh
> Looking around the Web, my first impression is that most version control
> systems are WAAAY more than I need as a solo developer. Plus, it looks like
> the free ones run only on Unix/Linux systems.
Subversion (also known as SVN) scales down to the single developer quite
well. There is a very good windows interface (integrates with Explorer
as a shell extension) called TortoiseSVN. It can be used without any
need for a server at all.
http://tortoisesvn.tigris.org/
http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html
In particular, this section
(http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-create-tortoisesvn)
deals with how to set up a repository that runs without a server.
Stephen Granade
I will third other peoples' suggestions of TortoiseSVN for
Windows. I've found it extremely useful for keeping track of IF files
under Windows.
Stephen
--
Stephen Granade
stephen...@granades.com
Jim Aikin
> well. There is a very good windows interface (integrates with Explorer as
> a shell extension) called TortoiseSVN. It can be used without any need for
> a server at all.
>
> http://tortoisesvn.tigris.org/
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html
Thanks. This looks like it might be exactly what I need ... but it's a whole
new learning curve. After perusing the Tortoise docs for half an hour, I
don't even know whether I need to install SVN and _then_ install Tortoise to
provide a front end, or whether installing Tortoise will automatically give
me a current copy of SVN.
Either that level of explanation is too basic for them to think their
readers could ever want it, or the manual is so dense that I breezed right
past the information with my eyes glazed. Either way ... not a good sign.
So I guess I'd better look on Amazon for a copy of "TortoiseSVN for
Dummies." Yeah, that's the ticket. Then I can get back to learning TADS 3,
or designing my next game, or whatever I thought I was going to do tonight.
I mean, they introduce the terms "trunk," "branches," and "tags" without
ever explaining what the terms mean, or how you would use a branch or a tag.
Like, I'm so embarrassed that I'm not an IT professional -- if I needed an
explanation, that would mean I wasn't a member of the club. (Must ... use
... telepathy.)
</whine>
--JA
Dannii
small. RapidSvn is available for both *nix and windows.
On Dec 15, 3:30 pm, "Jim Aikin" <raif...@musicwords.net> wrote:
> > Subversion (also known as SVN) scales down to the single developer quite
> > well. There is a very good windows interface (integrates with Explorer as
> > a shell extension) called TortoiseSVN. It can be used without any need for
> > a server at all.
>
> >http://tortoisesvn.tigris.org/
> >http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.htmlThanks. This looks like it might be exactly what I need ... but it's a whole
Timofei Shatrov
confuse everyone with this message:
>So my question for others in this group is, how do you do it? Copying the
>whole source code directory to a new backup file every day? Or is that
>enough? Do you incrementally rename source files? Keep a manually written
>log of changes? Do you have any software tools that help?
>
darcs. Very easy to install and use. No bloats, no GUI, all tools included into
the package. Nice documentation, too.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Neil Cerutti
I use CVS in the Cygwin Posix environment for Windows. If you
don't already use Cygwin, then it's probably better to use a
Windows port of CVS.
Here's a brief tutorial based on how I set it up a for my Python
port of glk.
First I created a directory somewhere on my system to hold my
repository of files. This is just an ordinary directory. Then I
told cvs that this is my repository by setting the CVSROOT
environment variable to that directory.
All code and code changes are kept in the repository.
Now I needed to add my project to the repository.
In my case, most of the files for glk.py existed in skeletal form
so I imported the whole directory to source control. From my
project's directory:
> cvs import -m "In the beginning..." glk me start
csv is the cvs program.
import is the cvs command I'm running.
-m "In the beginning..." sets the log message for this command.
If I don't set it with with -m, then an editor automatically
opens and I can set it there. cvs encourages you to set a log
message for every transation.
glk is the name I gave to the project.
me is the vendor tag. start is a release tag. The last two
arguments are not very important for a lone developer, but they
need to be included as a formality.
Now I could (and did) make a backup copy of my original sources,
and them deleted the original sources. cvs now contained them,
but I kept a backup because I was suspicious and a newbie.
Now, believe it or not, the hard part was over!
I checked out all the files in the project for editing.
> cvs checkout glk
This created a directory called glk, and my source tree got
pulled from the repository and copied into it. So you will want
to be careful about what directory you're sitting in when you run
the command.
-*-
So now I can work on my program. Periodically, I update the
repository and set a log message explaining what I just got done.
From my project directory:
> cvs commit
cvs scans all the files in the directory. Any of them that have
changed from those contained in the repository have their 'diff'
added to the repository, and then I get to write a log message.
As I add new files to my project (documentation, new sources,
tests...) I use the command
> cvs add FILE
where FILE is the name of the new file. The next time I use the
commit command the new files will be added to the repository.
I haven't needed to go back and fiddle around with any early
iterations of my project yet (so far, I've been moving slowly
forward) so I haven't bothered to learn the cvs commands for
querying file histories and backing out ill-advised changes, and
reading change logs.
I hope that gives some overview of how the process works. It
really is almost transparent once it is set up.
--
Neil Cerutti
The Pastor would appreciate it if the ladies of the congregation would lend
him their electric girdles for the pancake breakfast next Sunday morning.
--Church Bulletin Blooper
Andrew Plotkin
I find that, as a solo developer, I don't really use version control.
I make a backup every couple of work days (and keep it on a remote
server). I keep several stages of this backup for as long as I'm
working on the game, just in case I decide to go back and look at an
earlier version -- but I never *have* decided to do that.
In I6, I back up the whole source code directory (including the I6
library). In the I7 world, I'm still feeling my way -- my _Wallpaper_
backup contains the source code, plus a bunch of library and standard
rules that I copied out of the compiler. (That stuff is still changing
fairly often, as I7 evolves, so I want a good snapshot.)
If I wanted real source control, I'd set up SVN.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
You don't become a tyranny by committing torture. If you plan for torture,
argue in favor of torture, set up legal justifications for torturing
someday, then the moral rot has *already* set in.
Jon Rosebaugh
> Thanks. This looks like it might be exactly what I need ... but it's a whole
> new learning curve. After perusing the Tortoise docs for half an hour, I
> don't even know whether I need to install SVN and _then_ install Tortoise to
> provide a front end, or whether installing Tortoise will automatically give
> me a current copy of SVN.
I believe just installing Tortoise is fine.
>
> Either that level of explanation is too basic for them to think their
> readers could ever want it, or the manual is so dense that I breezed right
> past the information with my eyes glazed. Either way ... not a good sign.
I would posit a third explanation: the category of people who, like you,
read the docs before installing is an extremely small category.
> I mean, they introduce the terms "trunk," "branches," and "tags" without
> ever explaining what the terms mean, or how you would use a branch or a tag.
> Like, I'm so embarrassed that I'm not an IT professional -- if I needed an
> explanation, that would mean I wasn't a member of the club. (Must ... use
> ... telepathy.)
Sorry, my bad, I thought the Tortoise docs explained this in more detail.
Here's the relevant chapters of the SVN handbook:
http://svnbook.red-bean.com/en/1.2/svn.basic.html
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.html
For what it's worth, though, you'll probably never use branches or tags,
so you should be safe in ignoring them for now.
Jim Aikin
> I make a backup every couple of work days (and keep it on a remote
> server). I keep several stages of this backup for as long as I'm
> working on the game, just in case I decide to go back and look at an
> earlier version -- but I never *have* decided to do that.
After thinking about it, I think this is probably sufficient. My problem was
that I didn't keep incremental backups of all of the significant earlier
versions. This left me no way to recompile the Dec. 6 release in debug mode.
And of course, I can't reproduce the horrible bug that a player found in
that version. It works fine for me, and the source code would _appear_ to
make the bug impossible. The same thing happened a month ago, during
testing, but that bug was trivial.
In both cases, it seems something was changing a value of a property or
attribute from false to non-false or vice-versa. That's just not the kind of
thing I'd expect an interpreter bug to do -- but I have no other
explanation.
--JA
greg
> As I add new files to my project (documentation, new sources,
> tests...) I use the command
>
> > cvs add FILE
That looks a bit worrying. What happens if you
add a file but forget to "cvs add" it to the
project?
--
Greg
vaporware
Nothing will happen to the file, but it won't be saved in the version
control repository when you commit. You probably won't forget for long,
though, because you'll see the filename displayed with a question mark
in front of it every time you update or commit - CVS lets you know
there are files it isn't tracking. If you really don't want to track
certain files (e.g. compiler logs and binaries), you can add them to
your .cvsignore file and it'll stop telling you.
vw
Neil Cerutti
Then it will just sit there, and not get inspected by cvs when I
commit. If I were to delete that file, I wouldn't be able to get
it back out of the repository. Obviously, cvs doesn't keep
version inforamtion either.
So yeah, you have to be careful about that. cvs tells you which
files have changed during a commit, so if you are working on that
file you'll eventually notice that it's not getting updated in
the repository.
--
Neil Cerutti
Eric Forgeot
> So my question for others in this group is, how do you do it? Copying the
> whole source code directory to a new backup file every day? Or is that
> enough? Do you incrementally rename source files? Keep a manually written
> log of changes? Do you have any software tools that help?
I'm using rsync as a general backup tool. It's not only for code, but for
all my personnal files. It's incremential, so it backups only the modified
files, in a separate folder with the date.
Rsync exists on windows, but is considered outdated on this platform and ppl
advice to use Unison instead, which is much similar :
http://www.cis.upenn.edu/~bcpierce/unison/
Richard Bos
> > I find that, as a solo developer, I don't really use version control.
> > I make a backup every couple of work days (and keep it on a remote
> > server). I keep several stages of this backup for as long as I'm
> > working on the game, just in case I decide to go back and look at an
> > earlier version -- but I never *have* decided to do that.
>
> After thinking about it, I think this is probably sufficient. My problem was
> that I didn't keep incremental backups of all of the significant earlier
> versions. This left me no way to recompile the Dec. 6 release in debug mode.
Well, that's the very first thing I do - if I release anything, zip up
the release directory and archive it. Even if I don't have logs and
backups of every little change I made exactly as and when I made it, at
least I have every released version, with logs of what changed between
that one and the previous. I've never needed anything more.
Richard