🔒 Locked
version control system
Advertisement
Original Post
my project is nearing the need for a version control system, and since i lack the expertise or time to try the different systems, i am directing the question to the gdev community choices: CVS/CVSNT SVN ... (im not even gonna mention VSS since i hear its the biggest shit out there) i also would like the version control system to support/have -user permissions -simple administration -shell extension -VC6 plugin -messaging (sending other users messages/tasks) caesar
Personally I don't have a problem with Visual Source Safe 6.0. I am currently using it for a game project at school. It is being used to coordinate the efforts of a 4 person team working on the project. It allows us to always have an current build, and a way to roll back our code if we would happen to induce any major mistakes. However for the price of the software, I would take a look at CVS. Its all going to come done to price, and personal preferences. I also recall a similar discussion recently in the threads that you may want to do a search for.
- Bill
- Bill
I can recommend SVN. I've run it for two years, and it's really quite stable now. I recommend running the stand-alone "svnserve" server, which is really easy to install.
Other alternatives include Perforce (used by many games companies; pay-for unless you can get away with 2 clients only) or BitKeeper (used for the Linux kernel; free if you're OK with submitting your change logs for public scrutiny).
I'd put CVS above VSS, but below Perforce or BitKeeper.
Other alternatives include Perforce (used by many games companies; pay-for unless you can get away with 2 clients only) or BitKeeper (used for the Linux kernel; free if you're OK with submitting your change logs for public scrutiny).
I'd put CVS above VSS, but below Perforce or BitKeeper.
Quote:
Original post by caesar4
SVN - i read that it eats disk space like oprah if she were a program
- is there a cvs plugin for vc6?
VSS probably meets your listed requirements better than most tools, but I would encourage you to consider revising your list after using a tool such as cvs or svn. You can setup permissions with them, but it's a huge hassle for both the administrator and the developers. Per-project permissions is much easier for everyone.
The IDE plug-ins are really only relevant for pessimistic-locking source-control tools (which is not what you really want). They're not really needed for cvs or svn (or Perforce or Bitkeeper).
Both cvs and svn have a shell-extension tool, I don’t know if the others do or not.
SVN only has a disk-space issue if you convert a CVS repository to a SVN repository, otherwise it’s more efficient than cvs is.
Messaging is orthogonal functionality, consider using a separate tool. (Any suggestions? What servers are available for IM? Or H.323?)
I'll have to say SVN it was pretty simple to set up when I went to set it up. Only had a minor problem with it, that being I forgot to comment in a line in the config generated when I created repository. I use SVN for a server and TortiseSVN on my workstation and its great. SVN is very easy to administer on their site they have a link to a book about SVN avalible for free online. Which is a very good resource about SVN.
Also I can say Perforce is also very good, I haven't been using it verylong but I like it so far.
Also I can say Perforce is also very good, I haven't been using it verylong but I like it so far.
svn was created as a replacement for cvs, it fixes a couple of design problems without changing or adding the core functionality.
Both are open source and available on lots of platforms. For a small to medium sized team it should work fine, but understand you will need a linux server and someone who know how to work with linux to set it up.
There's cvsnt which is a cvs server for NT, it will be easier to work with if you have no linux experience.
...Is there a svn server for NT? I guess I just assumed there's not, but there might be!
Both are open source and available on lots of platforms. For a small to medium sized team it should work fine, but understand you will need a linux server and someone who know how to work with linux to set it up.
There's cvsnt which is a cvs server for NT, it will be easier to work with if you have no linux experience.
...Is there a svn server for NT? I guess I just assumed there's not, but there might be!
I'd personally avoid VSS at any cost, having suffered more than once the pain of it eating the repository for no good reason. At least with CVS everything's kept in RCS files, making retrieval possible unless the files have been actually been deleted.
I personally use Subversion, but if you do any branching, I'd advise against it since it's method is to pretty much copy the entire source tree and check it in elsewhere in the repository. All the other systems (with the possible exception of VSS) are much more sane in their branching demands.
That said, for a corporate VCS, while I've not used it I have heard nothing but goodness about Perforce. If you're willing to pay the licensing fees, it's worth it. I've also just heard about another system called Evolution, but I'm unsure of it's track record, if it has one.
In short:
Perforce > SVN > CVS > BitKeeper > VSS.
As for a VS6 plugin for CVS, I offer this: 1. You should seriously consider upgrading to VC++ 7.1 (VS.NET 2003) because not only does the compiler work better, it's also much more standards-compliant (no more need for STLport, they dumped Dinkumware's STL). 2. IIRC I did try one back when I used VS6, but it was poor and buggy. I found it easier to use the command line CVS tool.
I personally use Subversion, but if you do any branching, I'd advise against it since it's method is to pretty much copy the entire source tree and check it in elsewhere in the repository. All the other systems (with the possible exception of VSS) are much more sane in their branching demands.
That said, for a corporate VCS, while I've not used it I have heard nothing but goodness about Perforce. If you're willing to pay the licensing fees, it's worth it. I've also just heard about another system called Evolution, but I'm unsure of it's track record, if it has one.
In short:
Perforce > SVN > CVS > BitKeeper > VSS.
As for a VS6 plugin for CVS, I offer this: 1. You should seriously consider upgrading to VC++ 7.1 (VS.NET 2003) because not only does the compiler work better, it's also much more standards-compliant (no more need for STLport, they dumped Dinkumware's STL). 2. IIRC I did try one back when I used VS6, but it was poor and buggy. I found it easier to use the command line CVS tool.
Hey, guys-
I work at ionForge, makers of the aforementioned Evolution. There are free licenses available here . We also offer a big discount to gd+ members. It is a commercial quality system, so you get real support and usage/administration is much easier than with cvs ( speaking from experience there [smile] ). Give it a look.
Plus, you can get help from me here!
I work at ionForge, makers of the aforementioned Evolution. There are free licenses available here . We also offer a big discount to gd+ members. It is a commercial quality system, so you get real support and usage/administration is much easier than with cvs ( speaking from experience there [smile] ). Give it a look.
Plus, you can get help from me here!
SVN user permissions are easy to set up but not very granular. I use the server in daemon mode and I can only give people access to the whole tree or nothing. There's no way to give people access to just a section of the tree. But it still works great and in conjunction with SSH you can get a secure connection to your server from anywhere in the world.
-mike
-mike
If you want user permissions into your repository, you are doing something wrong.
You have to trust developers who can commit a single line of code, to get that single line right.
A single line can screw things up just as much as deleting the entire thing. As it's versioned anyway, they won't be able to erase its history, or their audit trail (Unless you're using VSS, in which case VSS will delete its own repository in a far more effective and subtle way than even the most malevolent disgruntled former developer could ever do).
I personally think you CANNOT reasonably give your developers commit access to less than all of your project. Either give them commit access, or insist that they send patches and manually go over them. There is no in between.
Mark
You have to trust developers who can commit a single line of code, to get that single line right.
A single line can screw things up just as much as deleting the entire thing. As it's versioned anyway, they won't be able to erase its history, or their audit trail (Unless you're using VSS, in which case VSS will delete its own repository in a far more effective and subtle way than even the most malevolent disgruntled former developer could ever do).
I personally think you CANNOT reasonably give your developers commit access to less than all of your project. Either give them commit access, or insist that they send patches and manually go over them. There is no in between.
Mark
I have to disagree with the idea that granular permissions are not necessary.
There are many situations when branch level security is needed. For instance, tech writers have no business in the developer's workspaces, developers have no business in the artist's branch. In a more extreme environment, at the enterprise level, many teams are on the same server, but have no business having access to another teams code. Or a group that works on an internal library that goes through its own development cycle and releases... no one else should have access to their code, and they shouldn't have access to any area that they will never be touching.
Then there's branching. Private, per-developer workspaces that get integrated into a main codeline. Each developer should only have access their own workspace and the rights to promote and harmonize their work into the main branch, but not to anyone else's workspace.
The list goes on and on.
Sending patches for manual line by line review is frankly unacceptable. It not only defeats at least 50% the purpose of source control in the first place (collaboration), but it's placing too much of a burden on the project lead.
In a small team environment, generally everyone will just have administrator rights, because hey, we're all friends. In smaller projects, you end up needing to touch everything, so most of the time you will need access to the entire tree.
It's not so much of a matter of trust (although in this day and age, you can not necessarily trust anyone), as a matter of segregation and insulation.
My four cents :)
Nick Ni
ionForge Company
There are many situations when branch level security is needed. For instance, tech writers have no business in the developer's workspaces, developers have no business in the artist's branch. In a more extreme environment, at the enterprise level, many teams are on the same server, but have no business having access to another teams code. Or a group that works on an internal library that goes through its own development cycle and releases... no one else should have access to their code, and they shouldn't have access to any area that they will never be touching.
Then there's branching. Private, per-developer workspaces that get integrated into a main codeline. Each developer should only have access their own workspace and the rights to promote and harmonize their work into the main branch, but not to anyone else's workspace.
The list goes on and on.
Sending patches for manual line by line review is frankly unacceptable. It not only defeats at least 50% the purpose of source control in the first place (collaboration), but it's placing too much of a burden on the project lead.
In a small team environment, generally everyone will just have administrator rights, because hey, we're all friends. In smaller projects, you end up needing to touch everything, so most of the time you will need access to the entire tree.
It's not so much of a matter of trust (although in this day and age, you can not necessarily trust anyone), as a matter of segregation and insulation.
My four cents :)
Nick Ni
ionForge Company
Permissions also help prevent accidents -- especially in a system like CVS and SVN where simply modifying a file indicates that it should also be modified in the repository.
What about Gnu Arch? From the description it looks pretty similar to Bitkeeper. Unfortunately it lacks tools like Tortoise although there is a Gtk+ front end. I've never used it but I'd like to hear if anyone has experience with it? I'm a fan of patch based versioning due to the flexibility that comes with it. Arch seems to have a neat concept, so it might be worth a try.
(I'd still recommend SVN to the original poster because there are pretty good tools available for it and it's really easy to setup. And yes, svnserve works fine under windows. A small drawback is that it still lacks a good gui front end on OS X)
(I'd still recommend SVN to the original poster because there are pretty good tools available for it and it's really easy to setup. And yes, svnserve works fine under windows. A small drawback is that it still lacks a good gui front end on OS X)
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement