Closed Poll: New project, git or svn



  • Time to create the repo for a new project.

    Lets say, a small team, probably distributed.
    Hmmm, git or svn?
    Decisions, decisions.

    I know! Let the TDWTF decide. We haven't had a poll in a while!

    • git
    • svn
    • Send zip files through email
    • I'm not playing

    Filed under: Attempt 2


  • SockDev

    what, mercurial, cvs or vss weren't options?

    lame...

    well if i must weigh in on git vs svn i'm going to have to go with - are you sure i can't choose bazzar?- ..... git.

    mainly because it means i can get away with swearing by claiming it's the name of our VCS

    filed under: yeah, i cut and pasted, what of it?



  • I voted for zip files because PNG wasn't an option.



  • @Keith said:

    I voted for zip files because PNG wasn't an option.

    Great minds, and all that...



  • I voted GIT because distributed, but I have only ever used SVN, so I can't be sure.



  • I said svn because I've never used git and therefore I fear it.

    /expecting people to say I'd fear it more after using it/



  • I voted zip through email because the pass-around-a-USB-drive option is strangely missing from the poll.



  • I voted git because it's the first option and there was no option to pass around jpeg screenshots of your code.



  • I vote for Play in foobar2000.



  • @ben_lubar said:

    and there was no option to pass around jpeg screenshots of your code

    Don't you know better than to store your code in a lossy format? After a few thousand revisions, it's going to be almost unreadable.



  • I'm still waiting for someone to invent a lossy file archiving method that produces valid files when extracted.



  • You can compress text by simply removing vowels.


  • Discourse touched me in a no-no place

    Bah, no FILE_NOT_FOUND option.

    You could have at least put a dummy FILE_NOT_FOUND in there ;-)



  • REPOSITORY_NOT_FOUND? <description



  • NOREPO WONTFIX

    <!-- body is invalid, try to be more descriptive -->


  • FILE_NOT_FOUND_OPTION_NOT_FOUND 



  • I want to, for example, give it a gzipped ASCII file and get back a gzipped ASCII file, even if it isn't the same one. Or a Word document containing a photo of a wooden table and get back a valid Word document with a photo of a different wooden table.



  • Send zipped files through e-mail is not a barrier to FILE_NOT_FOUND



  • You could probably work with whitespace shenanigans. Newlines in particular.



  • @accalia said:

    what, mercurial, cvs or vss weren't options?

    lame...

    We have what we have. Also, these VCS-s are for pussies.

    @hungrier said:

    I voted zip through email because the pass-around-a-USB-drive option is strangely missing from the poll.

    Tried it once. Never again.

    @ben_lubar said:

    I voted git because it's the first option and there was no option to pass around jpeg screenshots of your code.

    Oh come on guys, this is a serious question. Don't be so irresponsible.

    What if some junior follows your advice and then later can't OCR it back? And all he needed to do was follow the best practices and use png instead.

    @DoctorJones said:

    Bah, no FILE_NOT_FOUND option.

    No. Everyone would click that then.

    I'm being serious here. Tomorrow morning I'm closing the poll and whichever option has more votes, wins.



  • Would that be considered lossy? I think adding and removing whitespace at known places is simply a matter of adding and removing redundancy.



  • @cartman82 said:

    Oh come on guys, this is a serious question. Don't be so irresponsible.

    You must be new here? Coding Help category is :arrow_lower_right:over there.



  • @cartman82 said:

    I'm being serious here. Tomorrow morning I'm closing the poll and whichever option has more votes, wins.

    Except "send zip files through the mail", just to be clear here.



  • Depends on what the other contributors are most used to. I'd say Git if and only if everybody has a client they like and know how to use it without a week of research.



  • @blakeyrat said:

    Depends on what the other contributors are most used to. I'd say Git if and only if everybody has a client they like and know how to use it without a week of research.

    No idea who contributors will even be. Boss is still in the "get the clients" mode, he has yet to start running around, looking for people who can code the damn thing.

    But either way, I can get them set up with TortoiseWhatever, which will ensure they get pretty much the same interface.



  • SVN the git repository, then put that in a second git repository for backup.


  • Discourse touched me in a no-no place

    @cartman82 said:

    No. Everyone would click that then.

    I'm being serious here.

    Fair enough, I can respect that





  • @LoremIpsum said:

    Would that be considered lossy? I think adding and removing whitespace at known places is simply a matter of adding and removing redundancy.

    Who said anything about adding the whitespace back in? There's no real requirement that it the removal is deterministic.



  • @cartman82 said:

    Except "send zip files through the mail", just to be clear here.

    Fine, I'll change my vote.



  • Even if you don't care about the "D" in DVCS, of those choices Git has so many advantages (e.g. git add --interactive/--patch) that for me it's a no-brainer. The difference from CVS to SVN is still much bigger than the difference from SVN to Git, but the latter is a much bigger improvement than I'd have said before I used Git for a while. I use Git for all my personal projects.

    But... I'd strongly consider Mercurial. From what I can tell (admittedly, I haven't really used it all that extensively) it has enough to make me happy, and it omits some of Git's... well, Git-isms.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Depends on what the other contributors are most used to. I'd say Git if and only if everybody has a client they like and know how to use it without a week of research.

    I think I may be misreading this. It looks like you're actually saying that there are people for whom Git is usable.



  • Git is better than SVN technically in a few ways, especially if you go whole-hog on feature branches. I have kind of a love-hate relationship with the tool itself. (I definitely hate the idiot developers responsible for it.)

    The question is whether the few places where it's technically better outweigh the awful usability, and that's why I say only adopt it if everybody on the team is comfortable with it and/or has a good client they like.



  • @EvanED said:

    But... I'd strongly consider Mercurial. From what I can tell (admittedly, I haven't really used it all that extensively) it has enough to make me happy, and it omits some of Git's... well, Git-isms.

    But is it worth the effort securing the server for it, setting it up, learning it and forcing it on others? All that for a few nicer commands?

    Dunno. Like it or not, SVN and git are accepted standards these days (and TFS in MS-land). The others could be slightly better or worse, but I don't think they bring anything good enough to turn the things around.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Git is better than SVN technically in a few ways, especially if you go whole-hog on feature branches. I have kind of a love-hate relationship with the tool itself.

    This is interesting. You used to have a much worse opinion of Git. What happened to change your mind?



  • @antiquarian said:

    This is interesting. You used to have a much worse opinion of Git. What happened to change your mind?

    I don't think I have changed my mind.


  • Discourse touched me in a no-no place

    I must have misunderstood you then. No worries, I'll just go back to not taking you seriously.



  • @antiquarian said:

    I must have misunderstood you then. No worries, I'll just go back to not taking you seriously.

    @blakeyrat never changes his mind. His mind changes you.


  • Discourse touched me in a no-no place

    Why not just do the collaboration by sharing the code on a Wikipedia user page? Like that you can do open source and have all the tracking and history and backup you need, and all without needing to dedicate a server to the task; someone else is doing it for you!

    Only 95% joking…



  • Poll closed. Seems like gits have it.

    And I deliver. CARTMAN ALWAYS DELIVERS.
    (renamed folder to main because that's better suited to git workflow)

    Well, this poll was pretty fun. I think I might do something like this in the future too. Like "which tie should I wear" or "should I marry this girl or not"... little things to brighten the day.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    . I'd say Git any cvs if and only if everybody has a client they like and know how to use it without a week of research.

    HTH, HAND etc.



  • I don't always use Source Control, but when I do, I use a crusty old pile of sticky notes.



  • I think you mean bug tracking! Sticky notes are pretty damn hard to execute.



  • I've tried bug tracking, but it is very hard... they run to the loo and jump into the streams of water and then I cannot follow them any more.


    Filed under: saw that trick in an old Western.



  • I tried to reopen the poll, but it was already open



  • I closed it once this morning. It seems SOMEONE has decided to play smart.



  • LemmingSVN!

    Yes, I know the stereotype about lemmings is false



  • @cartman82 said:

    But is it worth the effort securing the server for it, setting it up, learning it and forcing it on others? All that for a few nicer commands?
    I know your poll is closed now, but I'll give you my thoughts anyway.

    First, bearing in mind that I'm a researcher and developer rather than a sysadmin, I'm not sure what the difference would be in server setup between the two. The vast majority of projects I've worked on have had access to both via SSH, and the remainder by local file system access. Both methods were used by both SVN and Git.

    I definitely think learning it is worth it. Forcing it on others is where I get a bit more uncomfortable, but I also think that basic usage is easy enough that I don't feel too terribly awful about that.

    I'd also say it's more than "a few nice commands." To repeat what I said in another thread, the closer you get to considering your repository itself as a useful artifact (so you can look up how features were introduced, bisect to find problems, etc), the more Subversion falls in comparison to Git, and the more Git provides more than just some convenience features.

    I should have also said there's one game-changing reservation that I have with git, which is if you have a large codebase that wouldn't comfortably fit into a single git repo, particularly if it would make sense for people to check out different parts of it depending on what they are working on. (E.g. my company puts everything into one bigass SVN repo, parts of which are specific to project1 or project2 and parts that are common to some or all of them, then you check out the parts you need for whatever project you're working on.) You can't do the latter with Git at all, so you have to break them up and use submodules or something, which are like svn:externals if you've used that. And like svn:externals, managing projects with submodules is a lot more complicated and annoying than something you can do all in one repo. (submodules and svn:externals are pretty different in an important way, but it's not clear to me which one works better & easier in practice. Probably Git's because it is more powerful in a useful way, but that also makes it a little more complicated.)



  • OK, this was why git wins over SVN. I get all that, I knew about the large repos, knew about the submodules.

    The question was, why chose, let's say, mercurial over git? What are the advantages and do they merit all the hassles stated in my post?



  • I'm sorry, I totally misinterpreted your question (obviously).

    I thing Hg falls into the same boat in terms of server: the setup is basically identical to Git, so that means the same things I said about servers are the same.

    Learning: if you know Git, Hg should go pretty quickly; see http://mercurial.selenic.com/wiki/GitConcepts. If you don't know Git, the same thing I said applies (worth it), only even moreso maybe because the learning curve is less sharp. And for the same reason, I'd feel a lot better about forcing it on others.

    Hg is noticeably more user friendly, especially for people who have used VCSs before. About the best you can say about Git was that it was designed with an explicit non-goal of making it like existing software; in actuality, there are a couple things where it almost seems like it was designed explicitly to be difficult for people used to other software (e.g. git revert is a subcommand that exists and does something different from every other version control software ever¹). Git also has some terminology issues, like having five names for the same freaking thing (you git add to update a file, at which point it is now staged for commit; you can look at changes in the index with git diff --cached).

    So Git vs Hg is a very unclear choice. If you don't have infrastructure set up for either, then it is probably about the same for both. If users will be using primarily the command line interface, Hg is probably better to use. If users will be using primarily the Tortoise{Hg,Git} UI, I actually like TortoiseGit's rather more, though I did manage to put it into a weird state once where I "had to" drop to the command line; I've used TortoiseHg's less, but it's less integrated to the shell and is closer to a standalone client program. I don't have other experiences with GUI interfaces.

    ¹ This is probably a lie.

    Edit I should also say my experience with Hg is a lot less with Git. Hg makes learning easy stuff easier, but I haven't tried harder things. Hg does have things like the rebase extension, but if it doesn't work as well as Git's, or if patch queues don't work as well as the index, that means that Git makes "harder" stuff easier and "which is easier" becomes dependent on whether you think you'll be doing more hard stuff or more easy stuff, and that goes back to the same (though much less extreme) tradeoff of Git vs SVN: the more you view your repo as an artifact, the more you'll be doing hard stuff.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.