2

In out current project we are using VSS and SVN to keep track of the versions. For some reasons the developers in our site are not allowed to commit in them. So when many developers work with the same file, we run into versioning issues. It is very difficult to keep track of it. Can anyone suggest a version control system? 

   1. It should be light-weight. 
   2. We are going to manage individual files. Not whole projects.
   3. It should have a GUI.
   4. Learning curve should be reduced to a minimum.

Not sure if these are high expectations, but do let me know about your thoughts.

altern
  • 5,829
  • 5
  • 44
  • 72
Vinoth Kumar C M
  • 10,378
  • 28
  • 89
  • 130
  • SVN kind of already fit the bill, and you don't actually need to setup a server for it. as the repository could be read of a filesystem. – dvhh Jan 13 '11 at 10:19
  • 1
    The problem isn't finding a version control system to use, but putting to use _what you have_. What is a VCS good for that nobody is allowed to commit to? _That_ is your problem, and that needs fixing. – sbi Jan 13 '11 at 10:20
  • The problem is the guys on the other end are scared we will do some "unwanted" commit . So they dint want to give commit access . I need something other than SVN to use. I do not want the guys on the other end to know we are using a versioning system . – Vinoth Kumar C M Jan 13 '11 at 10:36
  • 1
    I understand not wanting to give filesystem write permissions, but commit rights? Damn, there's some insane people out there. If the devs cannot commit, who does? – R. Martinho Fernandes Jan 13 '11 at 10:56
  • Yes . People here are insane . Thats how the whole organization is structured . So this is a problem . Is there a solution for this ?. – Vinoth Kumar C M Jan 13 '11 at 11:08
  • 1
    @vinoth: Lemme get that straight: You aren't given commit rights. As an attempt to patch over that stupidity, you want to setup your own VCS. But _you want to keep the knowledge from "them"_ that you had to do this in order to be able to work with the insane conditions "they" set up? That's like curing a belly ache by pulling a tooth and trying to not to let the patient know about it... – sbi Jan 13 '11 at 11:15

2 Answers2

3

For multi-site development, a DVCS (Distributed Version Control System) is actually recommended because it allows:

  • private commit
  • "backup" publication (you push your branch which will then be mirrored in the remote repo, still as your branch: nobody will be impacted)
  • common publication: you push a common branch (which you have pulled first to take into account other commits)

That publication workflow (orthogonal to branching) really opens more possibilities in term of code management.

Pick one (Git, Mercurial, ...) and you have a valid solution to your issues.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

To elaborate on VonC's answer a DVCS would allow all the off site devs to commit to one server but allow the onsite devs to control (by pulling) what is mergred into their controled branch/repo if they want.

i.e. if the onsite guys are scared of you commiting it is probably because they dont understand bracnhing and merging. and at the moment DVCSs are the kings of branch and merging

jk.
  • 13,817
  • 5
  • 37
  • 50