Versioning for a single developer project

[pcmattman]

http://github.com/aptana/

I'm not sure if that project is just laid out poorly, but if you can show me where the source is(without actually using `git`) in that project then I'd be thankful.

You judge an SCM based on how one project manages their repository layout? Try a project with a simpler repository layout, maybe?

I find git to be massively confusing in my limited exposures of it... I especially get confused at the multiple "repos" per project bit..

man git.

Seriously though, if you don't take the time to actually learn git, you will get lost, and you will get confused. It's not just something you pick up and try for a couple of minutes and then switch to something else.

and I don't like that you have to download the entire git repository/project in order to get the latest revision.

man git-clone.

You want a shallow clone:

Code: Select all

git clone --depth 1

Why you'd give up every good feature of git in order to save a little bit of bandwidth is beyond me though (especially since everything gets saved as diffs rather than storing the entire file for each revision).

Yes, git is confusing. No, it's not right for everyone. But if you're going to complain about it, please at least try and do some research first.

EDIT:

To actually contribute to the discussion (;)), the only time I haven't recently worked on a project with an SCM - even a personal project - is the time when I made a massive mistake halfway through refactoring all my code and couldn't drop back to a "last-good revision." That hurt, a lot. Took a long time to get back to original functionality too.

[piranha]

I personally use google code's SVN system, because I'm comfortable with it, and I know how to use it. And for all of the reasons listed above...I can switch between my home desktop and my school laptop (bored in computer science? Get some coding done!).

I have nothing against git, I just don't see the point in learning a new system, and switching to it.

-JL

[quok]

But if you're going to complain about it, please at least try and do some research first.

OMGWTFBBQ! Are you advocating that we actually take the time to Google something or read about it on Wikipedia before making inflammatory posts? Dude, you are totally taking the fun out of being a troll!

[piranha]

But if you're going to complain about it, please at least try and do some research first.

OMGWTFBBQ! Are you advocating that we actually take the time to Google something or read about it on Wikipedia before making inflammatory posts? Dude, you are totally taking the fun out of being a troll!

Ohhh! You just got quok'd!
Actually, that was directed not at pcmattman, but instead toward the original recipient of the sarcasm...

wait, what?

To stay on-topic-ish: Another thing about versioning that I like: The sheer satisfaction when you get the damn code to compile and run correctly...and you can type "svn commit -m "Ha! Yes! It works! Intel can go **** themselves, I got vmm working! Now what bitches!!!!!!!!!"

-JL

[01000101]

But if you're going to complain about it, please at least try and do some research first.

Shhhh, ignorance is bliss.

Anyways, I personally prefer SVN and HG (Mercurial). I was using Google code for a while and it (by default?) uses SVN for its access.
My local projects, ones that don't push to the internet, are still using some sort of SCM (HG atm) and it makes life a whole lot easier when you sit back after a hard day of coding and committing, press the "run" button, and scream profanities when it fails miserably. I really like HG's web interface ("hg serve"), but I'm sure some other SCMs do this as well, makes readability 100x.

[Solar]

On the "git -> overkill" tangent:

Link to Thorvals talking about git

1) I don't like the arrogance he repeatedly expresses during his speech. In fact, I think Thorvals is a git.

2) git is *aimed* at a massive-parallel, multi-merge project (like the Linux kernel undoubtedly is). It's great for that purpose, no doubt, but many of its features, and its overall workflow, are especially aimed at that very purpose.

3) Those features and workflows make git less-than-straightforward to learn and use, especially if you had previous experience with "classic" systems (like CVS, SVN, ...).

4) For projects who do not have the requirements mentioned under 2), "man git" and "man git-clone" are, IMHO, overkill. Just go along with "XYZ checkout", "XYZ add" and "XYZ commit".

[Kevin]

1) I don't like the arrogance he repeatedly expresses during his speech. In fact, I think Thorvals is a git.

Well, that's politics. Politics is always a reason for and against everything.

2) git is *aimed* at a massive-parallel, multi-merge project (like the Linux kernel undoubtedly is). It's great for that purpose, no doubt, but many of its features, and its overall workflow, are especially aimed at that very purpose.

SVN works okay as long as every developer has direct commit access (and you either don't care about a clean commit history or use something like quilt on top). You don't need anything of the size of Linux to get to a point where this is not true anymore. Actually, it's not true for any OSS project that has a community that contributes.

3) Those features and workflows make git less-than-straightforward to learn and use, especially if you had previous experience with "classic" systems (like CVS, SVN, ...).

4) For projects who do not have the requirements mentioned under 2), "man git" and "man git-clone" are, IMHO, overkill. Just go along with "XYZ checkout", "XYZ add" and "XYZ commit".

Just go along with "XYZ clone", "XYZ add" and "XYZ commit; XYZ push". So the push is the overkill?

That these commands are not mentioned in "man svn" is not a plus, by the way.

[Combuster]

In fact, I think Thorvals is a git.

Nice pun there

SVN works okay as long as every developer has direct commit access

Versioning for a single developer project

Erm, right.

Other than that, OpenTTD uses SVN (and branches and everything), I regularly see the bot post the commit logs, yet I never saw the problems mentioned... Nor would I know how that would happen if I would have more than one developer on my OS...

[Kevin]

You're assuming that projects that start out as one-man projects will stay such forever? (The original poster seems to do so, but I think this is questionable). But yes, we've gone a bit off-topic since the original question was answered with "yes".

For OpenTTD, I don't have insight on how their community works. Someone who doesn't have commit access to a SVN project very likely uses either something like quilt on top or something like git-svn as a client.

[thepowersgang]

Just to put my own two cents into this discussion.
I love git, even though there is only me working on it, it seems to be a simple, but effective system, that is easy to work with. (and it has saved my code many times)
It seems to be just personal preference, I use git because I was taught it by my friends, others may use SVN or CVS or any other type because that is what they know, in terms of effectiveness in a single developer project, almost all are equally effective (although the ability of git to reside in a hidden folder in your primary tree and not need a sever is quite useful)
The difference will come in when projects start expanding to include extra developers, but for a single developer project, just stick to what you know.

[earlz]

But if you're going to complain about it, please at least try and do some research first.

OMGWTFBBQ! Are you advocating that we actually take the time to Google something or read about it on Wikipedia before making inflammatory posts? Dude, you are totally taking the fun out of being a troll!

Are you saying that Git *should* be so complicated that you must read the man page to even understand how to get the source code through a web interface!? (that may be an attack at the web interface and not git itself though)

And yes, that is a poor example of a project, Pedigree is very straightforward... I guess bad tree layouts exist in ever SCM.

I think Git is too complex for most every project I've seen.. The learning curve of it is very high compared to other SCMs. I mean, I taught my boss at work how to use SVN in like 5 minutes. "right click and do `svn update` when you want to pull down the latest changes. right click and do `svn commit` when you want to save your changes to the repo." Very simple. Very straight forward.... Maybe the problem I have with Git is the mindset that if your going to make a change somewhere you might as well make a branch.. This is what Git is designed for, so it's no wonder everyone automatically thinks its the right way to do things with Git. To me, it feels like an over complication though..

and how has this topic not got split yet? lol

[Brynet-Inc]

I mean, I taught my boss at work how to use SVN in like 5 minutes. "right click and do `svn update` when you want to pull down the latest changes. right click and do `svn commit` when you want to save your changes to the repo."

TortoiseSVN != SVN.

But yes, SVN is nice.. CVS is fine as well.

I do not like git.

[XanClic]

Are you saying that Git *should* be so complicated that you must read the man page to even understand how to get the source code through a web interface!? (that may be an attack at the web interface and not git itself though)

Hu, that's funny. I tried once to clone an SVN repository and even after reading (OK, I didn't read it very carefully) the manpage I couldn't figure out how to do so. In the end I used git-svn to clone it as a git repo (and I didn't use that ever before, too, so I also had to read the manpage of that).
(And, btw, web interface != git. Most web interfaces offer you a function to download a tarball, though.)

I think Git is too complex for most every project I've seen.. The learning curve of it is very high compared to other SCMs. I mean, I taught my boss at work how to use SVN in like 5 minutes. "right click and do `svn update` when you want to pull down the latest changes. right click and do `svn commit` when you want to save your changes to the repo." Very simple. Very straight forward.... Maybe the problem I have with Git is the mindset that if your going to make a change somewhere you might as well make a branch.. This is what Git is designed for, so it's no wonder everyone automatically thinks its the right way to do things with Git. To me, it feels like an over complication though..

Hm, I rarely create branches... Most of the time I simply change my code, go to that directory, use "git commit -a", enter my commit message and "git push" if using a remote repository... Don't know what's so hard about that... Maybe the most complexive task of all these is entering the commit message because it uses vim as a backend.
And if I want to pull the latest changes I use exactly that command, called "git pull", although we're talking about a single developer and that's not necessary there.

I think the hard parts about git start, if you're not the only developer and/or if you want to use branches (with rebase, patches, and all that). But we're not talking about that here.

PS: I have to admit that I've never used another VCS than git, though I heard somthing about SVN and it didn't seem too straightforward to me... Furthermore you need a remote server (don't you?) for that, and sometimes there are good reasons why I don't want to do that (for example a 512 bytes contest which hasn't started yet ). Yeah, I could use a password-protected server or anything like that but why if I don't want to publish my code and no other developer is there?
But any good reasons why to use SVN instead of git are very welcome, of course.

[Kevin]

Are you saying that Git *should* be so complicated that you must read the man page to even understand how to get the source code through a web interface!? (that may be an attack at the web interface and not git itself though)

Hm, I've never used github before. Clicked on a project, looked for a download link, found it on the top... Definitely works without reading documentation. It's not my favourite interface, but pcmattman showed you a simpler one and the one I'm used to looks clearer to me, too.

PS: I have to admit that I've never used another VCS than git, though I heard somthing about SVN and it didn't seem too straightforward to me... Furthermore you need a remote server (don't you?) for that

No, you don't strictly need it, you just need a repository separate from your working copy. It can be a local directory, if you like. Backup was mentioned a few times in this thread, so this is the reason why you want to have an external repository. However, with SVN this means that for almost any operation you need to access the server (obviously for commit, but also including log, diff, ...). So if you're offline you basically can't work. And if your connection to the server isn't really fast, you'll definitely notice the difference compared to working on a local repository as in git.

[pcmattman]

I mean, I taught my boss at work how to use SVN in like 5 minutes. "right click and do `svn update` when you want to pull down the latest changes. right click and do `svn commit` when you want to save your changes to the repo."

Whilst some Windows GUI someone made as a wrapper for SVN itself isn't actually a valid argument for SVN, I should probably mention that an application called "git-gui" exists which allows you to do most complex git actions with a simple point-and-click interface. Works on Linux and Windows, too.

Are you saying that Git *should* be so complicated that you must read the man page to even understand how to get the source code through a web interface!?

No, he's saying that maybe some software is complicated enough that you absolutely must read the man page to understand how to use it. Not every program in the world must be 110% intuitive from the second you pick it up. If you think that way, then you are setting yourself up to fail. I also just found "man gittutorial," so it's not like the documentation isn't there or anything.

I regularly see the bot post the commit logs, yet I never saw the problems mentioned

My most distinct memory in svn was conflict hell: early on in the project we'd be working on similar areas of the kernel and constantly stepping into what everyone else was working on. git's rebase does a better job of merging in this situation (there are still cases where it fails, such as where indentation completely changes style). That said, a single developer project won't really need to worry about conflict resolution (in more ways than just their SCM ), but I always think it's better to plan ahead and make choices early that benefit developers that might join the project later. After all, that's why we document and comment code, isn't it? Why not plan our SCM in the same way?

I come from the git crowd simply because git is an SCM which can manage my project efficiently, fits our workflow perfectly, and supports a variety of features which make my life as a developer easier. It's also handy that each developer has an entire repository checked out, as it means we can rebuild our remote repository if something goes really wrong (and it has gone wrong, multiple times).

Others come from the SVN crowd. I honestly don't blame them. SVN is very nice to use when you don't need/want to use the advanced features of git (and if you ever change your mind, git-svn exists). I personally used SVN for everything before I learnt about git.

I notice nobody has brought up CVS... Clearly nobody actually likes it (and for good reason)

Either way, an SCM is, like a code license or style, a fairly personal, project-specific choice. I think we could go on for days and days fighting to see one come out on top, but it's not going to happen in a community like this. Maybe we can agree to disagree?