Setting up a local SVN Repository

[trh411]

I want to learn devel/subversion so I've installed it and am looking to set up a local repository to manage my personal script/program development. After reading the documentation a couple of times, it seems as though a single repository (called Projects) with each script or program underneath with a trunk/branches/tags structure in each is the way to go. However, I've got one issue with which I'm grappling. In more than a few cases, I've got two and/or three versions of the same script/program, one in shell, one in Perl and one in C.

Question is, how best to organize the Projects repository so that I can retain all versions of my scripts/programs and manage them effectively? Could I import all three version items into the /trunk and use /branches, one for each language version?

 

[Anonymous]

... and am looking to set up a local repository to manage my personal script/program development. ...

One consideration would be, whether the svn revision numbers could be of any use in your records of the version history of your programs. I am also running a svn server for a variety of my personal development projects, and I use the svn revision numbers for version house holding of each.

For this to work, I created for each project a separate repository. Putting all projects into the same repository would mixup the revision numbers, i.e. a commit for project 1 would also increase the rev. number for all other projects.

Another consideration would be, if there could be the possibility, that you need to give access to one of your projects (but not to the others) to for example a friend. In this case, rights management is more easy, if that project would reside in its own repository.

At the beginning I also was tempted to install the "strongly" suggested trunk/branches/tags structure, only to find out, that branches and tags were useless for my personal projects, so for my newer ones I already forgot to create tag and branch directories.

Putting C, Shell, and Perl versions of one project in one repository looks reasonable to me, because I assume that you not develop them independently, but once you change something in C, you port the changes to the Shell and Perl version too, and vice versa. If you then commit all together you would have a nicely aligned automatic revision history by the way of the automatic svn revision numbers.

My suggestion would be:

Project-A-Repository
[INDENT]C
Shell
Perl
[/INDENT]

Project-B-Repository
[INDENT]C
Shell
Perl
[/INDENT]

Project-C-Repository
[INDENT]C
Shell
Perl
[/INDENT]
...

 

[trh411]

Okay, I see what you're saying. Originally I was thinking that I would have a lot of one or two script "projects", but the resulting number of projects and/or repositories would quickly become unmanageable. Now I'm thinking my concept of a "project" needs to be enlarged, maybe along the lines of the ports collection. I could group my scripts into "projects" such as sysadmin, development, network, security, sysutils, backup/restore, www, etc. That would make things much more manageable.

Thanks for the ideas.