How Do You Control Your Source Code?

[eluser]n0xie[/eluser]
It's like doing backups. Everyone knows he/she should do it, but most don't. Then one day you screw up, you find a backup from 2 weeks ago, and you just lost 2 weeks worth of work. Now from this point on you'll never ever make that mistake again and fix your backups properly.

The same can be said about versioning. It makes your work easier. That little change you made that accidentally broke something somewhere else, you can just 'undo' that particular change and it doesn't matter when you did it. It could be months ago. Now imagine for a second you did a change 2 months ago. And you have emailed yourself every release from that point. Then you need to undo that particular piece of code. What do you do?

Do you grab the backup from 2 months ago and discard all your changes you did since then? Do you manually go about editing every file that is affected? What if you code was all over the place?

All the problems disappear (ideally) when you use version control. And I haven't even started about branching It gives you the power to 'try out something new', without changing anything from your 'stable' code. If in the end it works, you merge it back with your trunk (or master tree) and your changes are now officially added. You decide your code isn't working, you throw it all away. You find out 2 months later the code you added isn't compatible with some 3rd party API or library? You just undo those changes.

So you see using revision control is a very powerful tool. Seeing as you are the sole developer and everything falls to you, I would agree with jedd and would recommend git.

[eluser]BrianDHall[/eluser]
Wow, this has all been a great help. I didn't realize version control worked like that. I'd heard of branches and merge and all that, but I didn't realize that's what that all meant. I guess if I set it up on my main server it would also allow me to easily get the current working version of my code at home when I last worked on it at work, and keep 'live, fully tested' versions at hand easily so if it turns out some major bugs are discovered weeks later and the site needs to go back to the way it was ASAP then hey, no big deal.

This is exactly what I was looking for. I'm going look over Git and SVN, and see which one seems to most want to let me get started with it without driving me nuts

[eluser]Knitter[/eluser]
Hum... must be my "annoy BrianDHall" day, not that I know or knew you

Though a bit late, you've probably have already chosen something, I'll leave my thoughts on what to use.

I've started using SVN while I was going through my Bachelors degree, about 4 years ago, and I have to say that it was the best thing I could start using. For small projects and if you are the only developer, and you always have internet access to the SVN server, I would say subversion is a nice choice, easy to set up, good server and client support, both in IDEs and dedicated clients, and easy to use. The *only* thing you need to understand is what a centralized version control system means. Doing commits, updates, merges, branches, etc., is quite trivial, even using a command line client, where one could expect knowing the commands would be an obstacle.

Git has become very popular, maybe because of it's creator, I personally prefer Mercurial, as it was the first I used, in what decentralized systems is concerned. It's philosophy is very different from SVN, but I find it's limitations, or design choices as you prefer, to be more annoying the those of SVN, not having a central location for my source, something that controls the quality of the code, is just moving the responsibility from the machine to the user, and users make more mistakes and use more time than machines.

Also it's performance issues, as noted by Linus, can be a downside if you, like me, need to do a lot of file control instead of "content" control.

But Git has it's strong points, like easy merging of branches, for example, or "content" control, but those are things small projects and teams, especially if branching is something not often made, don't use and end up being wasted. On a small team, using Git over SVN doesn't seem to me as an advantage.

Since I use version control systems, I can count by finger of one hand the times I really needed to branch something that I then wanted to merge into trunk, branching, and tagging, have always been used as a way to mark versions and to allow for support to be maintained.

Projects where many developers are creating diverging work, or experimenting a lot, will definitely be better off whit Git, projects where the team is closed, and the project sees little to no branching will make better use for SVN.

Of course, this is my opinion, based on my own experience, and is worth what all opinions are worth.

EDIT:
Oh I forgot, you had a question on how do we control our code... I use SVN , the client I use will depend on the OS I'm using, in Windows I use TortoiseSVN, on Linux and OS X I use the NetBeans IDE's client and the command line client depending on what I need. I always use a version control system and a bug tracker/project manager, currently I'm using Redmine, which I think is great. I can't really develop without the ability to control the source code, know how it changed, who changed it, having a detailed history, easy backups and the ability to have several programmers in the same project/file at the same time. I can't see myself managing a project/team without source control and bug tracker/project manager software.

Best regards,

Knitter

[eluser]jedd[/eluser]
Hi Knitter. I'm a bit of a git advocate / apologist (take your pick) these days, so I'll bite.

I'd recommend you watch the google-tech-talk that Linus gave a year or two ago - it's pretty lengthy (about an hour) but pretty interesting. Available [url="http://www.youtube.com/watch?v=4XpnKHJAok8"]here, at youtube[/url]. It addresses some of the points (and misunderstandings) in your post.

Git has become very popular, maybe because of it's creator, I personally prefer Mercurial, as it was the first I used, in what decentralized systems is concerned.

There was a lot of 'interesting history' wrapped up in the development of git, to be sure, but even if it was written by someone(s) else, it would have been adopted by Linus, and in all likelihood be as popular as it is now.

There's an interesting thread, dating back a few years, [url="http://lkml.org/lkml/2005/4/25/267"]over on the lkml[/url] that involved Linus and Matt, relating to performance and design of Mercurial, and comparing both to git.

I think your point illustrates a common trend though - we tend to prefer that which we play with first.

... I find it's limitations, or design choices as you prefer, to be more annoying the those of SVN, not having a central location for my source ...

I think you might be missing the point of distributed SCM's - and the first link I posted covers this several times over - you can have a central location for your git project if you want to - that's a social or semantic or usage consideration only, rather than a technical limitation. Compare and contrast cvs/svn where you are constrained by that design flaw.

... something that controls the quality of the code, is just moving the responsibility from the machine to the user, and users make more mistakes and use more time than machines.

If you're seeking something to save yourself from yourself, then you might be in the wrong profession.

Seriously,
a) if the quality of your code is at risk because of your choice of SCM, then you have far bigger concerns,
b) I can't see how a distributed SCM could possibly affect the quality of your code.

Also it's performance issues, as noted by Linus, can be a downside if you, like me, need to do a lot of file control instead of "content" control.

I'd be curious what benchmarks you've generated that show svn or mercurial to out-perform git, especially on common functions. Not quite sure what you mean by file control / content control here, either.

But Git has it's strong points, like easy merging of branches, for example, or "content" control, but those are things small projects and teams, especially if branching is something not often made, don't use and end up being wasted. On a small team, using Git over SVN doesn't seem to me as an advantage.

I think if you view your software choices in terms of non-wasted features, you might be missing the point again.

I reckon on a small team - but this isn't based on first hand experience of working within one - git would become even more compelling. And to clarify - I think this, because of its distributed nature, and not because there'd be less features being wasted.

Since I use version control systems, I can count by finger of one hand the times I really needed to branch something that I then wanted to merge into trunk, branching, and tagging, have always been used as a way to mark versions and to allow for support to be maintained.

I reckon that if your history with SCM's is with software that makes branching and merging expensive, painful, arduous, etc - that you'll certainly get into the habit of not using branches and trying to limit your need to do merges. I don't think that it necessarily follows that if you didn't have that experience from using svn, that you'd still adopt the same usage habits with another SCM.

Oh, and possessive its has no apostrophe.

[eluser]Knitter[/eluser]
[quote author="jedd" date="1254276124"]
I'd recommend you watch the google-tech-talk that Linus gave a year or two ago - it's pretty lengthy (about an hour) but pretty interesting.[/quote]
It was pretty interesting, I've watched it a few times

[quote author="jedd" date="1254276124"]
There was a lot of 'interesting history' wrapped up in the development of git, to be sure, but even if it was written by someone(s) else, it would have been adopted by Linus, and in all likelihood be as popular as it is now.
[/quote]
Indeed, a lot can be said about Git development, and any reason for it, but I think much of the hype about Git is due to the main developer/user, Linus and Linux Kernel project. At least that's the way it stated being known, nowadays I can't say that their role (the one of Linus and Linux Kernel) in the spread of Git is really noticed, now Git starts to show its features and is starting to get known by them, but I still feel that the Linus was a big leverage for Git.

[quote author="jedd" date="1254276124"]
There's an interesting thread, dating back a few years, [url="http://lkml.org/lkml/2005/4/25/267"]over on the lkml[/url] that involved Linus and Matt, relating to performance and design of Mercurial, and comparing both to git.
[/quote]
I shouldn't have mentioned performance, has I was thinking of very specific cases where Git looses a bit, maybe that's because those are the issues that Git doesn't address well, but that is a design decision of the Git makers, Git is not focused on managing source files but on managing the source as a all, managing the content of the project. Alas I have no benchmarks.

[quote author="jedd" date="1254276124"]
I think you might be missing the point of distributed SCM's - and the first link I posted covers this several times over - you can have a central location for your git project if you want to - that's a social or semantic or usage consideration only, rather than a technical limitation. Compare and contrast cvs/svn where you are constrained by that design flaw.
[/quote]
I never said I can't have a central location, I know I can, it's just that it delegates the responsibility for that central location from the machine, as played by the SVN server, to the user that is responsible for maintaining the "main" or "central" branch. SVN forces you to have a central server, Git allows you to have it if you want, but that central server is not really "central", it's just another branch. Sometimes I really need it to be central and to have a "commit-access" control for my users.

[quote author="jedd" date="1254276124"]
Seriously,
a) if the quality of your code is at risk because of your choice of SCM, then you have far bigger concerns,
b) I can't see how a distributed SCM could possibly affect the quality of your code.
[/quote]
It's not a matter of affecting quality but of not lowering that quality, of course, the code is made by programmers and they should be responsible for programming right the first time.

[quote author="jedd" date="1254276124"]
I'd be curious what benchmarks you've generated that show svn or mercurial to out-perform
git, especially on common functions. Not quite sure what you mean by file control / content control here, either.
[/quote]
Pointing you the the video you posted , there is a part where Linus talks about performance and how he chose to design Git so that the main focus is on branching and merging and on getting performance on those common tasks, also how Git will not have the same performance if you try something like getting the history of one single file, as Git doesn't keep track of files, it keeps track of the all repository, when you ask for a file Git will actually start from the top of the repo, and trim it down to the file you requested. As for content, I mean that Git is able to tell me where a given function has been moved to, even if it was sent across files, SVN on the other hand will not tell me this, it will focus on the file alone.

[quote author="jedd" date="1254276124"]
I think if you view your software choices in terms of non-wasted features, you might be missing the point again.
[/quote]
I don't view software choices that way, I see every choice as a pro/con ratio, the right/better tool for a given project considering the project's characteristics.

[quote author="jedd" date="1254276124"]
I reckon that if your history with SCM’s is with software that makes branching and merging expensive, painful, arduous, etc - that you’ll certainly get into the habit of not using branches and trying to limit your need to do merges. I don’t think that it necessarily follows that if you didn’t have that experience from using svn, that you’d still adopt the same usage habits with another SCM.
[/quote]
I didn't quite follow, and maybe I'm the only one, but merging with SVN has never been painful, branching is as simple as typing a command, tagging is even simpler. I don't merge branches because I never needed to. Of course, if branching/merging were very common, I would not choose SVN. That's my main point, Git will shine in every branch/merge, but if I have no such thing, do I really need to change from SVN to Git? Maybe you feel you will need Git in every situation, I choose the tool depending on the project characteristics.

Bottom line, I like SVN and Git, just feel that SVN shines on small projects with little merging and Git on projects where merging is a common task.

[quote author="jedd" date="1254276124"]
Oh, and possessive its has no apostrophe.
[/quote]
Damn, did I wrote those a lot?

And I have to say, the character limit is a bit hard on me

[eluser]jedd[/eluser]

... but I still feel that the Linus was a big leverage for Git.

Undeniably it was an influencing factor, and got it some exposure, but consider how often you run into BitKeeper shops (or even users) as a sign of how important the chosen SCM for the linux kernel is.

SVN forces you to have a central server, Git allows you to have it if you want, but that central server is not really "central", it's just another branch.

This is so subtle a distinction as to be meaningless, I think. Central is at best a matter of semantics in this instance. Your central server is your primary repository, the place people go for canonical copies of your codebase, etc etc. To me, the central server really is central (even if it happens to also be another branch).

Sometimes I really need it to be central and to have a "commit-access" control for my users.

The [url="http://progit.org/book/ch5-1.html"]Pro-git book[/url] has some bits on how to do this. Commit-access control is easily done using ssh, quite similar to how you'd do it with svn I think.

[quote author="jedd" date="1254276124"]
Seriously,
a) if the quality of your code is at risk because of your choice of SCM, then you have far bigger concerns,
b) I can't see how a distributed SCM could possibly affect the quality of your code.

It's not a matter of affecting quality but of not lowering that quality, of course, the code is made by programmers and they should be responsible for programming right the first time.
[/quote]

As I say, I can not see how an SCM could lower code quality. (Lowering implies affect, of course, but I feel we might be getting lost in the wilderness here.)

[eluser]Knitter[/eluser]

This is so subtle a distinction as to be meaningless, I think. Central is at best a matter of semantics in this instance. Your central server is your primary repository, the place people go for canonical copies of your codebase, etc etc. To me, the central server really is central (even if it happens to also be another branch).

You're probably right, nevertheless, I do give a bit more weight to the distinction, most likely due to my experience with both systems.

I'm not really an advocate for SVN over Git, if it works for you just use it, but I feel I never had the need for what Git offers. If the project needs Git features, I use Git, no second thought, if it doesn't then why use it? I think both have their places, and in a small team/project SVN works great.

The [url="http://progit.org/book/ch5-1.html"]Pro-git book[/url] has some bits on how to do this. Commit-access control is easily done using ssh, quite similar to how you'd do it with svn I think.

This one I didn't know, thanks for the link.

[eluser]K-Fella[/eluser]
I realise this thread is getting old, but I was wondering if i could get some advice. I'm basically in the same situation as Brian. I'm a freelancer (work alone) and have been working on a large CI powered site for a client the last few months. Everyday (when I've had enough coding for one day) I RAR the local folder into my Dropbox folder and it gets uploaded as my backup. Then I have to FTP into the site and upload the changes (on a live site too!).

I've known about version control for a while but never really understood how it's used. Does it make updating a live site easier? In order to use version control with your host do they need to support the type you choose? Are there vc tools for Windows that work just as well as for other OS's? I've search for articles on how to use Git/etc for web development and other related topics, but never really grasped the concept.

[eluser]jedd[/eluser]
[quote author="K-Fella" date="1274731260"]
I realise this thread is getting old, but I was wondering if i could get some advice.
[/quote]

Correct - it will pull in a bunch of people who don't loiter around the forums much anymore - best to start a new thread than revive one that's more than a month or two old generally.

I'm basically in the same situation as Brian. I'm a freelancer (work alone) and have been working on a large CI powered site for a client the last few months. Everyday (when I've had enough coding for one day) I RAR the local folder into my Dropbox folder and it gets uploaded as my backup.

git will help. Actually, any VCS will help, but git will likely be easier for you.

Daily archives means that the average impact of a disaster is 4-5 hours of code lost - worst case is a day's worth. This seems an excessive risk.

Then I have to FTP into the site and upload the changes (on a live site too!).

{blink} Well .. while you're in the market for modern technology, check out scp/sftp too.

I've known about version control for a while but never really understood how it's used.

Be more specific - what, that this thread didn't cover, are you having troubles with?

Does it make updating a live site easier?

I think so, yes. It makes it more manageable, certainly. Updating a site should be fairly painless even if you're just FTP'ing up a tarball and doing a roll-in/roll-out process.

In order to use version control with your host do they need to support the type you choose?

(mostly) Yes. You should find most places will support git these days. I suspect you could even install it manually if they didn't have it bundled already. OTOH if you currently use FTP, they might not be particularly modern.

Are there vc tools for Windows that work just as well as for other OS's? I've search for articles on how to use Git/etc for web development and other related topics, but never really grasped the concept.

I don't use Microsoft Windows, so can't comment from direct experience, but I gather that the state of play of git on that platform these days is pretty good.

Install git, and run through some of the easy stuff at:
[url="http://spheredev.org/wiki/Git_for_the_lazy"]http://spheredev.org/wiki/Git_for_the_lazy[/url] and
[url="http://www.kernel.org/pub/software/scm/git/docs/everyday.html"]http://www.kernel.org/pub/software/scm/git/docs/everyday.html[/url]

Do some examples, use gitk to get a graphical look at the results, look at the Network stuff on github, etc.

Then read through the pro git book at : [url="http://progit.org/book"]http://progit.org/book[/url]