3

OK, I've been convinced that SVN is the way to go in a previous posting, but I haven't yet seen the epiphany. I'm not sure how I would set SubVersion up for my development environment.

Here's my current setup. I'm not keen to mess with it and it would be really nice if subversion could sit alongside it:

Work:

N:\Projects
N:\Projects\Lib
N:\Projects\App1
N:\Projects\App1\Help
N:\Projects\App1\Images
N:\Projects\App2
..etc

N: is on a separate server in the building.

There are several other development machines with the tools installed locally, but all development takes place referencing the files on the server - i.e. no source code is kept on the workstations.

Home

Laptop with same development toolset, and the sources in c:\Projects\App1.. etc, i.e. a mirror of the setup on n:\Projects at work.

The sources between N:\Projects and C:\Project are currently kept aligned with a custom app in conjunction with DropBox. File exclusions make sure that non-source files don't get sync'ed

I want to run SubVersion with this setup.

  • Where do I put the Repository?
  • Assuming I can have the repository in a mutually accessible place, will SVN remove the current need to sync between work and home?
Community
  • 1
  • 1
rossmcm
  • 5,493
  • 10
  • 55
  • 118
  • 1
    If you seem to like having silos so much, consider Git or Mercurial. Subversion is a centralized version control system, and either (as Greg H says) you replace your network folder with a subversion server, and the server is the authoritative source, not the network folder. To sync from work to home, you would be much better off with Mercurial than subversion. – Warren P Mar 11 '11 at 01:20
  • 1
    I'd add, since you're not committed to any SVC yet, take a really good look at both GIT and Mercurial. Sure your head would be spinning after dealing all that new technology at once, but be sure you make an informed decision. For example I used SVN for a while and mvoed to Mercurial. SVN is *grate*, but I like Mercurial's merge philosophy a lot better. – Cosmin Prund Mar 11 '11 at 07:08
  • 1
    As long as you can access work from home you can easily (i.e. VPN) use SVN as well, there will be no difference using a VCS or DVCS. If you need to work disconnected then a DVCS is better. –  Mar 11 '11 at 10:46
  • 1
    The only DVCS I have experience with is Mercurial. I chose it because it's "merge" behavior is very good, check out it's "changeset" concept. And being an DVCS I now have a complete backup of all my repositories on multiple machines, including my home Desktop and Laptop. That's also nice! – Cosmin Prund Mar 11 '11 at 12:25
  • Mercurial is AWESOME. It's my favorite. I really hate how merging works in Subversion, and I hate its branches-are-folders thing, and the lack of real tags. – Warren P Mar 12 '11 at 03:55
  • @gabr, I've been spelling "tortoise" wrong all these years... – rossmcm Mar 12 '11 at 19:31

5 Answers5

8

In order to embrace Subversion, you will replace your shared source directory with a Subversion repository that lives on the server. Each developer workstation will check out a copy of the whole source code locally (however, this could be a private area on a network server if you like).

You could retain your N:\Projects tree as a read-only copy of the daily build, or whatever. But one of the goals of Subversion is to mediate between two people editing the same file at roughly the same time. This is not compatible with a shared directory containing writable source code. Also, having multiple developers "share" the same Subversion working directory in some way is doomed to failure.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
4

Why not create an internet accessible (free) trial Subversion account, and play around a bit, to get yourself familiar, before you move your entire source code tree into it. Just so you don't delete everything you own, by accident. Maybe start with one dummy project. Host something on the internet. Without even paying a cent, you could use this site:

http://www.projectlocker.com/

Then you can set up your very own starter subversion server. You can create a brand new Delphi application (file -> new delphi application), and add a button, and double click that button, and write a message box thingy, or whatever it is you like to do in demo apps. Now create a subversion repository (perhaps they call them projects, up on project locker), and add the folders you saved this project into, to that repository.

Now you can play with (a) tortoise SVN, (b) the SVN integration build into Rad Studio XE, if you have Rad Studio XE, and (c) the version control plugins that come in the JCL, if you don't have Rad Studio XE.

Also, may I suggest that if you want to have any hope of knowing what you're doing you learn how to add and commit, and update, from the command line. It's really not that hard. And it will pay off later.

Knowing you can type svn co http://reposite.something.com/svn/myproject to check out a project to your disk, is very handy. Sometimes, I think GUIs are training wheels for your brain. You cripple yourself if you don't learn command lines.

A benefit to a hosted subversion service like the one I showed above, is that you have an offsite backup. Of course, such hosting is always free even for large projects, if you are writing something open source. Then you can host on sourceforge. Otherwise, you're going to (a) need to use your own internet accessible host or (b) pay for hosting, otherwise you're not going to be able to easily access your repository at home, and at work.

Personally, if it was my own business, or my professional job to write software, I would host my own subversion server, and it would be private (LAN) only, and I would use a VPN to access it from home.

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • 1
    +1, having an account to play with is very helpful. Remember when I made the jump, I was doing all sort of tests: Checked the code out to multiple folders, made intentional changes to the same file on multiple copies, played with merges. – Cosmin Prund Mar 11 '11 at 08:06
3

1: You definitely want a repository accessible from both locations. Either that, you you will need to use a distributed versioning system, like Mercurial or Git

2: Yes, there will be no more need for your custom sync app. This is exactly the job for your versioning system. Syncing manually in addition to using SVN is not necessary and would even create lots of conflicts.

Adrian Grigore
  • 33,034
  • 36
  • 130
  • 210
  • so how do I go about creating a repository that is accessible both from work and from home? Do I need to find a SVN server and install it? Will it work over the web so that the home machine can have access to the same repo? – rossmcm Mar 10 '11 at 23:49
  • You have to install a subversion server to do ANYTHING with Subversion. A client alone doesn't do much for you. A subversion client without a server, is like a web browser, without any web servers. You can't anything with it. – Warren P Mar 11 '11 at 01:23
  • 1
    @Warren P: Not quite. Actually you can have subversion synchronize changes with a repository on your local harddisk or even shared disk in your LAN. But I agree it's not a viable solution for this. – Adrian Grigore Mar 11 '11 at 10:16
1
  1. Your shared directory should be removed and a copy of the code present on each machine that is a working copy of the SVN repository.
  2. Use your server with the files to place the SVN server on it or any server that all including your home computer have access to.
  3. Commit / Update every day, multiple time a day and manage merges if needed .

For the home access the simplest is to either get a dedicated server on the net or redirect the correct port on your router (but you will obviously need some access control in place) so that your repository is accessible from outside. If needed you could limit access from your home IP or from a list of IPs with a good router.

The other solution as other said is another kind of version system called "distributed" where every commit is done locally in your own repository on your own PC and this repository is merged on the "main" repository to share code and the change of other members of the team are pulled back in your local repository (You don't need any "main" repository technically on a DVCS but for a company that's what you will have).

See Git or Mercurial for good DVCS (Git syntax sucks but it's the most widely used system and technically the best one).

Julien Roncaglia
  • 17,397
  • 4
  • 57
  • 75
1
  1. Put the repository in the safest place. That usually means a good redundant server (disks, etc.), in a controlled server room, and one which is properly backed up. When you switch to a VCS, source code to work on is typically in local machines sandboxes, because each developer must have its own. Then changes are get and sent to/from the server. Be aware that some tools may have issue is on a remote directory, because of the way for example the SMB protocol works - check they are supported explicitly if you need to use them. Unless you have paramount security needs, IMHO working in local sanboxes is faster and easier.
  2. If you can access the SVN server from home (i.e. via a VPN), it will be not different than working from the office. You will "sync" (update/commit) your laptop sandbox the same way, you don't need a local server and repository. If you need a local server (reason could be you can't access the central repository from outside, need to work disconnected yet version files, etc.) there could be ways to replicate across SVN servers, but at that point maybe a distributed VCS should work better in such scenario.