4

I am working on two different project simultaneously where whenever the changes are made we use

  1. Tortoise SVN for project A
  2. Backed up by folder for Project B (this is done by me on my system)

I find SVN good for maintaining the latest code server machine and update it whenever necessary.
For Project A, I happen to make alot of changes to the project A and I am advice not to commit the changes again and again but just a major change all at once.
But since in not alone on project A I tend to make code backs by folder every time I make an important change so I can go back and return if some conflict occurs.

But what should I do in case of the project B?
where most I am on the project (as of now).
Should it be SVN or folder backups?

The reason I do folder backups for the project B is that
sometimes the build given to the client fails/buggy so instead of making them wait for it to fix
I just go and open the project and compile the last working build and give the executable so they can carry on their work and not wait for me to fix it (may take long).

I am working with Delphi on both the projects.

3
  • Why are you giving your client a buggy product?
    – Ramhound
    Dec 14, 2011 at 12:28
  • the software im working on requires hardware to test if everything is working fine or not,since we dont have the hardware in the office ,we make/code the changes asked for by the client and the executable is given to the client which is then tested on the actual hardware, so that time/later they encounter bugs...hence the build is buggy in that sense Dec 14, 2011 at 12:42
  • Remember that if project B were also in svn, then you would be able to update your working directory to the state at any commit, not just the states you decided (at the time) might be useful. What if you took a copy on the 10th, fixed a bug on the 11th, and on the 12th added a feature and made another copy. If you later wanted to go to the version with the bug fix but not the feature, you couldn't. With svn you could. I always use source control (mercurial at home, git & svn at work), even for the smallest projects. It just doesn't male sense not to.
    – Mark Booth
    Dec 14, 2011 at 15:29

4 Answers 4

19

im advice not to commit the changes again and again but just a major change all at once

It's wrong advice.

project B where most im on the project (as of now) should it be SVN or folder backups

You should use version control in any project.

Backups and version control are not the same thing, although an external repository (centralized, or distributed in another computer) is a backup in itself, and backups (e.g. dated folders or zip files) together with some diff tool (e.g. WinMerge) could serve as a very rudimentary version control tool. But since excellent version control systems are available for free, there's absolutely no excuse not to use them.

Of course, backups must be taken in addition to using a version control system.

1
  • 1
    so svn is the way to go..nicely explained Dec 14, 2011 at 11:28
10

The reason I do folder backups for the project B is that sometimes the build given to the client fails/buggy so instead of making them wait for it to fix I just go and open the project and compile the last working build and give the executable

This is precisely the problem source control is meant to solve (using branches/tags). You would do yourself a favor in the long term by switching to SVN. You will realise how wise such a movement was (would have been) the first time you need to provide a hotfix to a bug in an older version while you are in the middle of developing a new feature in the latest version, which must not be deployed yet. With SVN, merging between different branches is way easier and safer than manual diff & merge between different backup directories.

1
  • Ok so in the long run the SVN will come to the rescue, i think i should really switch to svn Dec 14, 2011 at 11:29
4

You could switch to mercurial (distributed version control). This way you can commit as often as you want (on both projects).

In project A once you have reached a critical mass of commits that are acceptable you can all push them to the subversion repository (using HgSubversion*). If the number of commits is a Problem you can use either mercurial queues (Tutorial) or make a little home-made fix by rewriting all your commits into one. For example export them all as patches -- easily done with TortoiseHg -- and then import them into the repository again. Then commit and you have all your changes in one commit.

*To use HgSubversion you need the Python SVN bindings. In TortoiseHg (Windows mercurial client) these are included so you just download the HgSubversion source, include the path in the hgrc file and are ready to go.

1
  • Use a source repository for all of your projects, as @JoonasPulakka and @PéterTörök wrote.
  • Backup your entire source repository daily on another server/drive. Corruption/loss of source repositories may happen, and it is the only way to recover the the whole history of your changes, not only the last version. There is a question on SO on what is the best way to backup an SVN repository.
  • Tag/Branch your minor/major changes. If one of these builds is released to the client, and fails, you should be able to fix that branch and release a fix, and report the change to the HEAD branch. Sometimes, though, there may be valid reasons to not fix a previous version (as you mentioned), and releasing the latest version that already fixed the problem may be the best solution. Anyway, this is your choice, and the only way to be able to fix a previous version is to have it in the repository, AND to tag it appropriately.

Edit: on the subject of SVN, as @PéterTörök wrote, merging branches is way easier than with some other source repositories, you already made a good choice there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.