Syncronizing Source Code

Usually teams use a revision control system like Subversion, CVS or git. I personally prefer Subversion with TortioseSVN.

From what I gathered, lots of busy code repositories (kernel source trees and the like) are moving away from SVN to gits. I personally use SVN, too, because it's simple to use, and I'm not going to switch away from it anytime soon; but for new projects, you should investigate both.

Quote:

Original post by Konfusius From what I gathered, lots of busy code repositories (kernel source trees and the like) are moving away from SVN to gits.

They aren't moving away because of activity levels (plus, the Linux kernel was never in Subversion; it moved from CVS to git - not gits) but because distributed revision control is a better model for a substantial number of geographically dispersed contributors. Specifically, the ability for individual contributors to publish changesets containing their own changes only, which repository maintainers can selectively integrate, is an essential advantage when you consider how time zone differentials can impact the update-checkin cycle.

Further, in the case of kernels, user contributions tend to be complete feature enhancements in isolation, with minimal source code interdependency. In other types of projects, however, you are constantly refactoring code that other modules depend on or publishing new interfaces that other modules consume.

If your team is largely local, or within the same time zone, then git/bazaar etc may not constitute an advantage because of the overhead of integration maintenance. Picking an appropriate revision control system requires you to understand the nature of your project's development.

Ok, I will try them both out and see which one fits the project better. I'm looking to get about 10 programmers to help on the project, so CVS might be the way to go. Most of the current programmers are not local and are somewhat scattered across timezones. Thanks!

EDIT:
Ok, I downloaded the binary for CVS, and I have no clue as to how to install it. I have a shared hosting account on godaddy, and I don't think it's possible to run applications on their servers...

I looked up how to actually use the program, and it looks like everybody has to use shell commands and such to connect. I'm asking since I'm not a programmer, but do most programmers know how to use CVS or git? Thanks!

[Edited by - taelmx on April 13, 2008 1:53:42 AM]

Quote:

Original post by taelmx ...CVS might be the way to go.

If you're thinking of CVS, use Subversion instead. Subversion was designed to rectify CVS' most glaring shortcomings, without fundamentally altering the revision control philosophy.

Subversion looks like it requires a hard install too, is there any sites that offer subversion already set up on a server or is there a php script for version control? Right now I'm using plain FTP, and I don't want stuff to be overwritten.
Thanks!

I've been using Unfuddle to host my svn repository. I don't know how big of a project you are running, but their free setup has been enough for me for the time being.
All you would need to do is:
1. Setup a project at Unfuddle
2. Download TortoiseSVN
3. Tell TortoiseSVN to checkout from the link given to you by Unfuddle.
4. Add all of your current code using TortoiseSVN.
5. Commit your changes through TortoiseSVN.
6. Now you have your software under version control.

Of course there are other sites out there if Unfuddle doesn't meet your needs, but the premise remains the same.

Quote:

Original post by taelmx Subversion looks like it requires a hard install too...

What do you mean "hard install"? If you're referring to the difficulty of the installation, Subversion is very easy to install. If you're referring to having to install it on the server, well... duh.

There are an abundance of sites that offer Subversion accounts for free, but they may impose different restrictions, and they will control your access to your code. Depending on your project, that may or may not be acceptable. Click here.

Quote:

Original post by Oluseyi They aren't moving away because of activity levels (plus, the Linux kernel was never in Subversion; it moved from CVS to git - not gits) but because distributed revision control is a better model for a substantial number of geographically dispersed contributors. Specifically, the ability for individual contributors to publish changesets containing their own changes only, which repository maintainers can selectively integrate, is an essential advantage when you consider how time zone differentials can impact the update-checkin cycle. Further, in the case of kernels, user contributions tend to be complete feature enhancements in isolation, with minimal source code interdependency. In other types of projects, however, you are constantly refactoring code that other modules depend on or publishing new interfaces that other modules consume. If your team is largely local, or within the same time zone, then git/bazaar etc may not constitute an advantage because of the overhead of integration maintenance. Picking an appropriate revision control system requires you to understand the nature of your project's development.

Why would a distributed tool have more maintenance overhead? You don't *need* to have some guy selectively integrating all incoming changes (although it's nice to have the ability to work that way). You can just set up a dumb copy of the repository that everyone pushes to whenever they want. The overhead would be about the same as CVS/SVN.

To me the biggest hurdle to getting people started on git/bazaar/mercurial, is the time it takes for new people to learn how to use them. The learning curve for these tools seems to be much steeper than for CVS/SVN.

Quote:

Original post by pinacolada Why would a distributed tool have more maintenance overhead? You don't *need* to have some guy selectively integrating all incoming changes (although it's nice to have the ability to work that way). You can just set up a dumb copy of the repository that everyone pushes to whenever they want.

How, then, do you publish a single coherent release version? I probably need to do more research into the issue, but there's a reason there are repository managers for each branch of, say, the Linux kernel.

Quote:

Original post by Oluseyi How, then, do you publish a single coherent release version? I probably need to do more research into the issue, but there's a reason there are repository managers for each branch of, say, the Linux kernel.

You can just say, "Okay guys, server X is the single release version, if your changes aren't on server X then they aren't in the release." And you can set up access so that everyone on your team can upload changes to server X whenever they want. The distributed tools don't prevent you from using a centralized model of development (which is good, because the central model is still the most appropriate model for many situations).

Also, the tools generally make it pretty easy for you to configure a certain server as "the one true server". In Git, the command to send your work to another place is "git push ". But you can set up a default, so that you can just type "git push" with no server name. Ditto for the command "git pull" (which updates your copy of the repo with changes from somewhere else).

I think the reason there are so many managers of the Linux kernel, is more to do with human issues than any limitation of Git. They have lots of committers, they don't necessarily trust the work of these people, and the stability of their product is really, really, really important. So they *want* to have all incoming work be reviewed by lots of eyeballs.

Quote:

Original post by pinacolada You can just say, "Okay guys, server X is the single release version, if your changes aren't on server X then they aren't in the release." And you can set up access so that everyone on your team can upload changes to server X whenever they want. The distributed tools don't prevent you from using a centralized model of development (which is good, because the central model is still the most appropriate model for many situations).

I suppose that works on the small scale, but doesn't that get unwieldy as the number of developers increases? Also, in the absence of a repo maintainer who decides what gets merged in, how are conflicts avoided? Say that 3 of your 100 developers all modify file A.cpp, in approximately the same place, how are conflicts resolved without explicit oversight? Does a subsequent commiter get a notice when a changeset conflicts with the current state of the given server/repo?

To my mind, revision control systems are technology for the codification of software development cultures appropriate to the organization and project. Distributed revision control makes sense in a culture where an individual developer may do "breaking work" in a personal branch for a sustained period and then integrate into mainline, but where you don't want to establish a dependency on other aspects of that trunk - or, at least, that's how I see it. Am I seeing it wrong?

Quote:

I think the reason there are so many managers of the Linux kernel, is more to do with human issues than any limitation of Git. They have lots of committers, they don't necessarily trust the work of these people, and the stability of their product is really, really, really important. So they *want* to have all incoming work be reviewed by lots of eyeballs.

This speaks to my culture comment above. What benefit does distributed revision control present when you have a limited number of contributors in relative physical proximity or at least coherent time zones?

Quote:

Original post by Oluseyi I suppose that works on the small scale, but doesn't that get unwieldy as the number of developers increases? Also, in the absence of a repo maintainer who decides what gets merged in, how are conflicts avoided? Say that 3 of your 100 developers all modify file A.cpp, in approximately the same place, how are conflicts resolved without explicit oversight? Does a subsequent commiter get a notice when a changeset conflicts with the current state of the given server/repo?

You still have the idea of a master or trunk branch, and this can be managed however the project sees fit - the idea central to all decentralized version control systems is that whenever you make a modification to anything, you are working on a branch, albeit that branch may be the projects trunk but its still a branch.

Quote:

To my mind, revision control systems are technology for the codification of software development cultures appropriate to the organization and project. Distributed revision control makes sense in a culture where an individual developer may do "breaking work" in a personal branch for a sustained period and then integrate into mainline, but where you don't want to establish a dependency on other aspects of that trunk - or, at least, that's how I see it. Am I seeing it wrong?

The advantage that the newer source control systems bring is ease of merging branches. Have you ever had to merge changes from a branch to trunk that has had some but not all of the changes that have gone into trunk since the branch point using subversion? It can get extremely difficult with having to keep track of the revision numbers to use. Ok scripts like svnmerge.py make things easier but still have their problems. Merging is soo much easier with git / mecurial, should there be any conflicts it is a case of fixing them as you would in svn and then committing.

Quote:

This speaks to my culture comment above. What benefit does distributed revision control present when you have a limited number of contributors in relative physical proximity or at least coherent time zones?

Again ease of merging, you have the complete source history on your local working copy (this means that backup strategies are not so essential as everyone has a copy of the full history so if the server goes down then you still have the full history available) and this full history is often smaller than a subversion working copy. Also in the case of git at least the lack of proliferation of .svn directories makes packaging far easier. Also distributed revision control allows proper disconnected working - if you are on the road for a few days and want to continue working you can commit to your local repository, creating branches, merging as necessary and then when you get back to your home network push your changes into the central repository. This alone to me is a very useful feature as I don't always have net access available but I can continue developing with full SCM features nonetheless.
Distributed version control software also tends to be a lot faster because you have the complete revision history available features such as blame, log are instant commands that don't require a trip to the server as using svn requires. I know of situations where people have avoided using blame and log functionality of svn because of a slow connection (VPN via dial-up).

Thanks, jamessharpe! That was an excellently comprehensive overview, and I think I've sorted out the core differences now. I had understood the ability to work in proper disconnected mode, but I didn't realize that each user had a full copy.

Thanks again.

Just thought of one other advantage and that is the ability to switch quickly between branches. I have worked on a large project with svn and working on multiple branches at the same time meant I needed to have a complete copy of the source for each branch (I found svn switch too slow for switching between branches as it required the server to do a complete diff of the tree I currently had and the branch I wanted to switch to), whereas with git I am able to have one working copy and switch between copies in an instance.

Quote:

Also, in the absence of a repo maintainer who decides what gets merged in, how are conflicts avoided? Say that 3 of your 100 developers all modify file A.cpp, in approximately the same place, how are conflicts resolved without explicit oversight? Does a subsequent commiter get a notice when a changeset conflicts with the current state of the given server/repo?

This works pretty much just like SVN. If you try to push and there's a conflict, you first need to resolve the conflict locally before you can put your changes on the server.

Quote:

What benefit does distributed revision control present when you have a limited number of contributors in relative physical proximity or at least coherent time zones?

Along with all the things jamessharpe brought up, here are a few situations that are much easier to deal with using Git/Mercurial/etc than with CVS/SVN. These are all things that commonly happen even when your contributers are right next to each other.

- You're halfway done on some big new feature that's not ready to be put in trunk yet. Some bug report comes up and you know it will be a super quick fix. You need to 1) save your work somewhere, 2) make the quick change, 3) test this quick change, 4) send it off, 5) get back your work. (Here you could put your work in a local branch or use "git stash")

- You're working on some feature (call it A), and you discover that to make A work, you need to make some other smaller change (call it B). Then as you're working on B, you find you need to make an even smaller change C. Since small, atomic commits are easier for other people to deal with, you want to send commits C, B, and A separately, and in that order. You also want to build & test each change before you send it.

- You and some other guy are working together on a new not-yet-finished feature. You want to just see the other guy's work, so you can test your stuff against it. But neither of you want to put your work in trunk yet.

Quote:

Also in the case of git at least the lack of proliferation of .svn directories makes packaging far easier.

Yeah, those .svn directories drive me crazy. I think they also hurt performance- when you do "svn switch", SVN needs to update the data inside every one of those directories, making the operation much slower. They also increase the number of possible ways that your local SVN copy can get screwed up (for example, if a .svn directory gets deleted).

my $0.02 - CVS is a fabulous tool, even if you are the only developer. If
you use a PC, also use the "Tortoise" shell extension, which makes using it
very easy and intuitive. The ability to look back and see any previous
version of a file is incredibly useful.

I found SVN to be overly complicated and confusing. CVS focus on single
files works fine for me.

Also, previous postings didn't make clear that routine changes, where
two developers change different parts of the same file, are handled
automaticlly 99% of the time. Much more reliably than attempting to
do the same thing manually in any case. This feature alone makes
using CVS/SVN worthwhile.

Quote:

Original post by ddyer I found SVN to be overly complicated and confusing. CVS focus on single files works fine for me.

I put forth the opposing opinion, that CVS is complicated and SVN is easier. SVN has concise commands and an easy to understand 'revision number' system. Neither is perfect however, merging with SVN isn't straightforward.

Quote:

Original post by Umbrae I put forth the opposing opinion, that CVS is complicated and SVN is easier. SVN has concise commands and an easy to understand 'revision number' system.

But remember that when you come to using branches too that its actually a 'revision number' + path that is required to specify exactly what you mean by the revision number. Its this idea of using paths to represent branches which I would consider broken design in SVN (although I agree its far better than CVS in other aspects to make this point secondary in the decision)