1

Currently we have code stored on a shared network drive and do not use any kind of VCS. The code stored on our shared network drive is always being backed up. We would like to keep things as close to they are now as possible, while using some kind of VCS software.

I am envisioning a centralized workflow with each developer having a local copy of the code on his/her machine. We don't do any branching or working offline. Typically when we spin off a new version we would just copy the current working directory to a new directory. I believe we would continue doing this and just create a repository for the new version.

I would rather not get into an argument over which VCS is better, just hoping to get some opinions for which is best suited and most applicable for what we are trying to do.

Improve this question
6
  • 3
    if all you want is the basic checkin/out of files all version control is essentially identical.
    – Ryathal
    Dec 14, 2012 at 16:45
  • 2
    The whole point of VCS is to avoid having 15 directories titled version1 releaseVersion etc etc. If your going to use vcs, use it the way it's meant to be used
    – daniel gratzer
    Dec 14, 2012 at 16:46
  • @jozefg: The changes Thomas is proposing are still a big step forward.
    – Brian
    Dec 14, 2012 at 18:25
  • After some further thought we most likely will be creating a new branch for a new version, however this does not happen very often.
    – Tommo
    Dec 14, 2012 at 18:46
  • @ThomasMancini: If you intend to work on new and old versions of your product simultaneously, creating a new version is an appropriate use of branching. If your only reason for creating new branches it to make it easy to find specific canonical versions within the repository, it is far more appropriate to use tags (AKA labels, depending on your VCS).
    – Brian
    Dec 14, 2012 at 19:15

3 Answers 3

Reset to default
3

Well, you tagged eclipse, so I would go with git, since its pretty well integrated with the IDE (with EGit). Also you can push on a network drive without having to set up a server like SVN. Plus if you ever decide to use more feature of your VCS you will have a pretty powerful and modern tool at your disposal.

Improve this answer
3
  • So a server is REQUIRED for SVN?
    – Tommo
    Dec 14, 2012 at 18:10
  • @ThomasMancini: You can install SVN on the machine you are using for your shared network drive. You will have one (unless using a DVCS) central location which is responsible for the current code repository.
    – Brian
    Dec 14, 2012 at 18:22
  • 2
    Well you don't need a dedicated hardware only for your SVN, but you do need to launch some central software that will open a socket and be up every time you want to commit (so yeah, in essence, a server). You can't just commit to any directory.
    – Laurent Bourgault-Roy
    Dec 14, 2012 at 18:49
6

Most, if not all, version control systems will be able to cope with your workflow.

You'll simply check out from a main trunk and check back into it when each development is finished. The developers will just need to get into the habit of doing a "get latest/head" at regular intervals.

It would be better to take a branch of the code for each new version, rather than a copy. Or perhaps create a branch to preserve the last version (it doesn't really matter).

What you'll probably find is that as you become more used to using version control you'll see more possibilities for using branches, so I'd pick one that has good branching and merging tools.

Improve this answer
3

Your workflow (of a centrally accessible folder with copies) would map to VCS like TFS and Subversion. Each of these relies con common access to a shared history. A VCS would be an amazing leap forward in terms of keeping track of changes to these folders, but the concept would feel the most "at home" with someone already used to working this way. I might have suggested Visual Source Safe (if it was 1998, ohh burn) because of the concept of file locking which I think is a side effect of your workflow. However in terms of training your team to work with a VCS the one big leap will be to understand that you will pull down a working copy when developing and you will need to push (commit) your changes in order to get them back onto the common code base.

Now if your team is used to having large copies of the their code on their computers and they see merging it with the shared codebase as a pain, then I would direct you tot Distributed Version Control. As mind bending as the concept is (here is an excellent resource, to get a team to understand it: http://hginit.com/), it helps speed up the process of synchronizing your teams efforts.

Improve this answer
2
  • Well currently we all access the files located on the shared drive. None of us have a local copy on our machines. One of the main reasons we want to switch to using a VCS is because of the size of our project and how it performs in Eclipse. We get stuck in clean/build loops that take away from our productivity and they take 5-10 minutes to complete.
    – Tommo
    Dec 14, 2012 at 17:46
  • Subversion is free, easy to set up, works on every OS and has great tool support for IDEs like Eclipse and VCS and even Windows Explorer. It's the gateway drug of VCS, you will want more trust me
    – Jason Sperske
    Dec 14, 2012 at 17:52

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.