I don’t get this. So GNOME is yet again switching repositories, this time to git. I know I spent a lot of time working with CVS when I was still very active on GNOME, and trash talking it made wonderful topic for conversation in your local pub. But any pain associated with switching to anything else is not outweighted by any benefits. OK svn was better. So what. For 99.9% of stuff, CVS does fine. Same story with git.
Don’t fix it if it aint broke. CVS is stupid at times, but it certainly ain’t broke. It is extremely well tested and has not given anyone any data corruption. The switch to SVN was a lot of pain for those involved I assume and there were some problems for some files. SVN is far less tested for doing bad stuff to your data, simply because of its age.
OK, so now we have switched to SVN and they (I am saying they since I guess I can’t consider myself part of the active GNOME developer corps) are switching to git. I still work on genius and very rarely on gob, so I still use the gnome repository. For me, actually svn was slightly more annoying than CVS. I’m fine with doing file moves on the repository or by deleting the file in the repository and checking it in under a new name. I am not such a perfectionist. I don’t expect someone to try to check out a working copy of GNOME 0.13 or some such. File history beyond a few years is probably useless fluff. So I didn’t quite see any benefit of moving away from CVS. But oh well, who cares.
Now git. Hmmm. This seems like a completely different beast meaning I’ll have to waste more time learning something new to do essentially the same thing with no new benefit. Why not move only those projects whose maintainers want to work in git, and leave those projects whose maintainers are happy with SVN in SVN? Hmmm. Ultimately I don’t care that much, I’m just annoyed. And I’m worried about data integrity of the little stuff I have in GNOME SVN.
Nobody can explain to me any actual advantages of git over svn or cvs. The only benefit I see is that git does things in a way that someone happens to think is the “correct way.” This is like th argument that gdm must use dbus for internal chatter of greeter with the daemon or within the daemon’s processes. There is no practical upside except someone’s warm feeling. Downside is always instability and breakage.
Just ranting … Ignore me …
The Spectre of Math 
> Nobody can explain to me any actual advantages of git over svn or cvs.
Umm… really?
git allows work “offline” much like svk, but without hacking svn. That’s a significant advantage for some people.
git has some very nice patch preparation and sending abilities, unlike anything I’ve seen in svn. (It’s kind of bound up in the DVCS aspect, you see…) So you can preserve commit history when submitting a patch. Another huge advantage for people without commit access.
I’m sure there are several things that I’m forgetting, but I will say that the switch to a DVCS from something like svn is a huge change and one with only one drawback: the learning curve.
I’m sympathetic to the conservatism in such things, but saying that there are no possible advantages to using git is wrong. YMMV but I think it’s more likely that you will change your mind within a few months 😉
–titus
Comment by Titus Brown — March 21, 2009 @ 3:25 am |
So your argument is good for managing “piece of shit code.”
Look, it’s been a couple of months. I am no longer a regular coder, I code up something every once in a while. As for getting used to git, well, you can get used to a wire stuck in your eye, that doesn’t mean it’s pleasant.
I don’t say that there are no possible advantages. I am saying that the added complexity far outweighs the rather small advantages. My biggest argument is for using in somewhere like the gnome vcs system. A very busy project with lots of developers in the vcs can perhaps make more use of the features of git, but the vast majority number of projects are not such. In my time maintaining pieces such as the panel, gdm, gnome-libs, etc… I have never encountered an issue where I needed more out of cvs than it could provide.
My point is that the learning curve from nothing to cvs is not that bad. The learning curve from cvs to git seems far larger. Meaning the learning curve from 0 to git is huge. That means lots of occasional developers will spend hours and hours figuring out git instead of writing code. The vcs system should be out of the way. A good vcs system should be EASIER to use than cvs, not HARDER.
The “patch preparation” stuff is nonsense. Sending patches is for occasional developers. Those are more likely to not know any git. Thus they will likely be making a patch against sources from tarballs. Plus hell, it is not hard to run diff. CVS makes it so goddamn easy to write a patch against anonymous cvs checkout. Any improvement in that comes up against the law of diminishing returns.
Comment by jlebl — December 9, 2009 @ 2:35 pm |
I doubt I’ll change my mind.
My main point is the law of diminishing returns. Doing things in a better way is not always better. In my opinion it will be a lot of wasted energy. Not that there may not be advantages, but that they are totally not worth changing something learning a new and more complicated system. There are ways that these things can work better. I cannot ever remember being actually frustrated by any cvs related nonsense. I can remember being at best offended by some ugliness of how things work, but never frustrated. The model of CVS is easy, I know exactly what it is doing, there is almost nothing to learn. SVN is slightly better and so what, but it is worse in other ways. From what I know of git, it is significantly different so that will probably be the most annoyed I will be with any version control system. Having to switch seems to me more pain than I have ever had with CVS/SVN.
Genius and gob (like 95% of all things in gnome repository) are very low traffic kind of things so … I really doubt I will have absolutely any use for any new features of git.
Anyway, even when I worked full time on GNOME on things that got a lot of patches. I don’t think I would get much mileage out of these advantages. I can already work offline I just don’t commit when offline. I like to go through patches carefully enough by hand anyway. When working on a large change offline, I would have to go through the actual code anyway if anyone was working on the same files. The less is done automatically the better, the less chance for bugs.
I liked to handle only one branch (HEAD) and at most one extra branch in a busy project when I need a both stable and unstable branch.
Anyway, just my opinion.
Comment by jlebl — March 21, 2009 @ 7:10 pm |
SVN was always seen as a stepping stone from CVS to a DVCS – the conversions tools for CVS->SVN are much better tested than CVS->DVCS.
My main complaint about git is you need to build a mental model of how it works before it’s really useful, whereas my ideal DVCS can profitably be used by a novice. Also the various ways you can fuck a git repo.
As for why git is better than CVS/SVN, being able to pick small fixes out of a patchset (cherry picking I think) for separate submission is very useful apparently. Speed is the other big one, plus http://whygitisbetterthanx.com/
Comment by James — March 22, 2009 @ 8:30 am |
Well, I can take a patch and use vi to pick small fixes out of a patch. I have to stare through the patch anyway to see what depends on what. No DVCS is going to understand the code to do that for me.
As for speed. I never saw speed as an issue. 99.9% of time is spend on coding (or should be). The most important is the code that is currently in the repository. I code, then I commit. At best I resolve conflicts, or perhaps I generate a patch against the branch I am working on if I’m sending a patch to someone. When I update I check what was changed.
Now that I’m mostly working only on genius, I need even less of vcs nonsense to get in my way. It seems that git just gets in the way a lot more, I will need to spend more time thinking about useless aspects of working on the project (basically added vcs bureaucracy). And as you say it makes it easier to fuck things up with git? Great! That’s what I always wanted to do. This should be a showstopper.
I also don’t get this obsession with DVCS. I don’t see the point of having all the changes stored locally except that I will take up disk space on several machines with stuff that I never use. And here is where speed can become an issue. I have sevral times needed to do a change in cvs from a machine without the repository installed. Do I have to pull in the whole repository to that machine (such as my work machine which has slow nfs drives with limited space, not to mention the time it probably takes to download the complete repository instead of just the newest version)? That sounds like a horrible idea. And I’ve done this many times before and probably would not be able to do it if using dvcs.
So my point stands. There are some things which work maybe theoretically better, but probably don’t improve or speed up my workflow at all. Then there are things that make my workflow from mildly more annoying to far more annoying. The biggest is to figure out how to safely work with a new system which does not help me do anything better. Simplicity is a virtue, and no DVCS is going to be simple, and as far as I see git is far from the simplest dvcs.
Comment by jlebl — March 22, 2009 @ 3:33 pm |
a VCS is not just a forward looking thing; it’s a “let’s look back at what we did and why” kind of thing also.
Especially when new people join the project, and they have to fix something in a piece of code they don’t (yet) know, a good VCS that can show them the history properly can make a lot of difference.
For me and my teams, the killer feature in git is that it can track the history of a piece of code (say a medium size, very critical, function) beyond refactors, file renames, and what have you.
If the refactor was the last thing that happened, most VCSs have probably lost all track of the code before that point, unless someone who *knows* about the refactor can tell you.
Git will say “hmmm, you’re looking at that function? well right now it’s in foo.c, but 2 months ago it was in bar/baz.c… want me to take you there?”
I find that most people who are satisfied with CVS are basically using it as a glorified backup system. No more. If that’s all you need, I guess I can’t blame you…
Comment by Sitaram — November 25, 2009 @ 3:24 pm |
I understand the ideas behind it. My problem is that git makes everything so much harder to use. If it easily tracked changes, then great, but as it is it doesn’t seem to do anything for me, except for taking up my time whenever it does something I didn’t quite understand. I don’t hack too often and for example genius has essentially me as the only contributor. There is simply no need for complicated change tracking in such a project, and I would bet in 99% of everything that is in the gnome git right now. When hacked on gnome, none of the projects (and I hacked on almost all of them) really required anything more complicated beyond cvs.
It’s nice to be able to track a piece of code when it moves between files. BUT it’s a feature that I’d use probably once every few years. And grep usually tells me quite easily where a function is. If you understand the code, then you don’t need git. If you don’t understand the code, you should not be making changes in it. I have not really seen the value in really knowing history of a piece of code. You need to know how it interacts with the rest of the code base at the current point in time.
I don’t use cvs just as a backup, I also like version tracking. It is useful to know what happened with the code recently, to be able to back it out etc…, but a simple diff is generally good enough. If you change your code so much that diff is not useful, then history is most likely useless. The other useful thing is merging between several people. Though if your work conflicts so that cvs can’t handle it, you’d better handle it by hand anyway. IMHO of course.
I simply do not trust software to understand what the code does. The smarter the vcs, the more subtle the screwups. No vcs will ever understand the code good enough to really be able to automatically track and merge all changes.
Comment by jlebl — November 25, 2009 @ 5:36 pm |
> I have not really seen the value in really knowing history of a piece of code
That says it all. You’re better off not using git, seriously.
However, in the commercial world you’re thrown into maintaining something that you did not create, and you know the problem is in that little piece of code but you can’t figure out (in the limited time you have) what the F that line is doing and why it was put in.
Two ways around. Your way is to understand the whole thing, at the current state. Good for you.
My way is to figure out when that line was put in, and — assuming decent commit messages (that’s another topic — small and granular commits seem to encourage really decent commit messages that are actually useful; something a CVCS would never manage, with the usual “commit everything when all done” mentality) — I can easily understand why that line was put in and what it actually means.
Comment by Sitaram — December 9, 2009 @ 3:06 am |
Heartily applaud your strong advocacy for
– efficient code management over efficient history management
– coding time over the time spent on tracing history
The above list of comments suggest that git is for the ones who are more “interested in things other that what they are doing” – coding in this case.
Though I am too noob to call myself a first hand user of any SCM, people generally claim being able to merge/manage faster with git. So should I assume that git is for the managers of code rather than for the coders themselves??
Another question – a bit out of the context – Do you think that we require men (or women) to mind what others do, managers that is, at all??
Comment by r43217 — July 2, 2011 @ 6:19 am |
also on second thoughts. Should I not :
$ svn co scheme://host.tld/svn/my-project/branches/my-branch-folder
# checkout remote branch
$ cd my-branch-folder
$ cd ~/myworks/my-project/branches
$ svn export /path/to/my-branch-folder my-unversioned-branch-folder
# create an unversioned copy
$ svn mkdir svn://user@localhost/svn/repos/myproject/branches/my-branch-folder/
# create a local svn branch
$ cd my-unversioned-branch-folder
$ svn import svn://user@localhost/svn/repos/myproject/branches/my-branch-folder/
# import the unversioned copy
$ cd ..
$ rm -fr my-unversioned-branch-folder
# remove unversioned copy
$ svn co svn://user@localhost/svn/repos/myproject/branches/my-branch-folder/
# checkout the local branch
Now I believe here I can take advantage of speed in commits, and keeping track of my changes. Of course, I admit that these commits are not available/visible to the world. But small changes dont need to be notified. Whenever I reach a level, I can commit or scrap.
Besides, checking out a folder/subfolder is not allowed in git! I tried to git clone gimp-repository, ending up downloading 100MB vs 17MB tarball download on the ftp
However, svn seems to be apt choice for me while working with small projects.
Comment by r43217 — July 2, 2011 @ 7:11 am |
To be honest, I’m a bit surprised to see a post, such as this, from an author such as yourself. There are many, MANY features that make Git attractive over SVN:
1. Disk space- Git uses _substantially_ less disk space than SVN, usually on the order of 1/10th the size, and better (I personally converted a 60GB SVN repo at work to Git, and it ended up being 3GB).
2. Working offline- Everything is local. Users can track their own branches and edits, without communicating to a centralized server.
3. Branching is cheap- Pushing to a remote server, does not mean pushing all branches.
4. Distributed- Similar features of other DVCSs, you clone an entire repository, rather than individual branches/trunks/files.
5. Staging area- It’s trivial to commit only some modified files, rather than all of them.
6. Speed- It’s no contest. Git is much more performant than SVN. More performant than anything else I’ve seen, actually. Speed was a big design goal.
7. Exporting options- You can export/import patches in bundles, via email, …
8. Builtin docs- Git has much more documentation builtin to the software, than SVN. It’s much easier to learn as a result.
9. Dynamic workflow- Becuse Git is distributed, with the benefits of working offline, and powerful branching, highly complex workflows can be realized.
Really, SVN didn’t bring much to the table from CVS. It’s still CVS at the core. In fact, one of the main designs was to be backward-compatible with CVS. In fact, the motto of SVN was “CVS done right” for many years. It brought a few features, such as parsable output and full MIME support, but overall, it’s CVS with a different hat. Git was a radical shift to the way we think about version control. It was designed as a filesystem, rather than a traditional SCM.
I understand rants about jumping to the latest and greatest, because of bling factor, but if you’re seriously considering using a VCS, it’s hard to consider CVS, SVN or anything else, when you look at what Git brings to the table. From a purely logical, rational debate, when looking at the features, which Git brings many, Git, Mercurial and Bazaar usually win out, with Git on top, IMNSHO.
Comment by Aaron Toponce — January 1, 2012 @ 3:53 pm |
Yes, git has a lot more featuers and complexity than I think most projects need. There is no one canonical source, it is easy to branch and in fact git almost forces you to branch all the time, so you get branch explosion, with all the problems and bugs that creates.
Speed? Who cares! If you spend significant time fiddling with your VCS, you are doing something wrong IMO. If a commit I do at the end of the day is 2 seconds or 30 seconds, or 5 ms, I don’t really care. If I code I spent 99.9% of the time coding/compiling/testing, and the rest fiddling with git. Git is actually slower for me since with cvs I can just do a “cvs commit” and it will commit, on occasion it will force me to run update and merge first. With git I do a commit, because you can’t do a pull before commit, then you do pull, then push. Occasionally you need to do stashing. In any case, the number of commands I have to do doubles. The commands are just as slow because once you have to do a push or a pull, all speed is gone.
Documentation? You must be joking. Git documentation is written by people purposefully trying to hide what is truly happening behind a multitude of new terminology that is purely git based. Git has its own language which is one of the reasons why I hate it. It’s almost like a cult. I have never yet come away from reading some git doc understanding what just happened to my source (git did eat my changes several times). Plus if there needs to be extensive documentation for the thing, it is broke by definition.
Working offline? I work offline all the time. If I’m working on something with someone else, I’d better be online once in a while anyway to coordinate. git doesn’t talk to other people for you.
Highly complex workflows? That is a total buzzword nonsense. That means absolutely nothing.
My biggest gripe with git is it’s utter lack of simplicity.
Sofware should be as simple as possible, but no simpler. Conversely it should only be as complex as absolutely neccessary. Git utterly fails this criterion.
I don’t really care for SVN in that all it did was just fix a few nonessential problems with CVS while introducing its own issues. I’m perfectly fine with CVS. From a purely rational point of view, I would choose CVS. It is simple, it does all that is necessary, it is easy to understand, it doesn’t require spending days learning, you can esentially just start using it. I don’t care that it lacks some blingey features that I’ll never ever use.
Comment by jlebl — January 1, 2012 @ 11:17 pm |
Buzzword? Really? I can force Git to use an SVN-style workflow. I can force Git to use a master/minion workflow. I can force Git to use a managed diff/patch workflow. The point is, Git is flexible enough to meet the structure of my development environment. I’m not forced to use any specific way to push changes upstream. Seriously.
I agree speed doesn’t mean much, when you have small repositories. When they get large, it’s a big deal. And every corporation I’ve worked for, has had very large repositories. Why add time to your already long day? Saying speed doesn’t matter, is like saying you’re content with single-threaded applications, but you don’t need the extra ms saved per thread.
Personally, and this will of course vary for everyone, I didn’t have any problems learning Git. It just Made Sense ™. I still struggle learning the ins and outs, and the “proper way” to do something in SVN. I’ve not used CVS seriously, beyond the occasional pull/update.
To each their own, but my response was to address the advantages Git brings to the table over others. They are advantages, even if you don’t use them.
Comment by Aaron Toponce — January 2, 2012 @ 5:39 pm
Advantage that you do not use is not an advantage. Plus anytime someone says “workflow” the hairs on the back of my neck stand out. The computing world is so full of buzzwords it’s not even funny. Though it always was, it’s just an unfortunate disease. That’s why I was saying that using git is CS masturbation.
Actually just have to address your “multithreaded” comment. It would be a good analogy if it actually worked. The problem is that except for bling, my computing environment 10 years ago was faster. A terminal came up immediately. OK, compile times were a little slower, but even vim seems to have gotten slower over the years. There is an actual delay nowdays when I press alt-tab, and when I want to look at the list of applications there is a 10 second delay before the list of applications shows. So much for multithreaded apps. The panel was single threaded, ran on a far worse processor, and I made the menu show up more or less instantaneously.
Same with web browsing. The browser, despite someone telling me it is faster is getting slower and slower. Websites have more and more code in them for doing absolutely the same thing they were doing before.
Jiri
Comment by jlebl — January 2, 2012 @ 8:11 pm
I find really impressive and even good to see the “other opinion” about version control systems.
I love git. Really do, like someone who does researches about it on the free time.
But all of these tools are a matter of necessity. Git is for those who needs branching, and a distributed workflow is something wonderful (yeah, sending patches by email for the main team “works”, but doing a pull request – in the case of github – is so much easier). Also, is a pain in the ass to start contributing to some old open source project which uses SVN, which takes forever to checkout.
But if you have a VCS which works, I don’t really see the point of trying to change it for one which has more features just for the lulz – unless the features are something the team needs.
The Linux team, for instance, couldn’t afford to the patch system anymore (oh, I made a change! Here is the patch. Oh… one hundred patches. Fuck =D). So there it goes git.
Really, congratulations for you if you have the balls to maintain your opinion about CVS and SVN. It’s something rare to defend any of these VCS. But remember that all of these softwares appear as someone’s necessity. Nobody wakes up someday saying “hey, I’ll do a VCS because it’s cool to say CVS and SVN sucks”.
Comment by Yuri Albuquerque — February 1, 2012 @ 4:11 pm |
Yup, that is really my point. Maybe something like git is really necessary for the kernel which has thousands of developers working on the same files. But 99% of software out there has 1-2 developers and you get an outside patch every once in a blue moon. There is no reason to commute to work in jumbo jet if I can get there by a bike. There is no reason to learn emacs or vi if all you need is to edit a webpage once in a while. That was an argument for the decade before. I always just used some vi clone, even though emacs was the in-thing to do. Use the right tool for the job. In the end, git just like cvs or svn is a tool only. Having your code in git or cvs or just having the files on your disk without any vcs doesn’t say anything about your code. It doesn’t make your program better or less buggy. I know a lot of crappy code that is in git. I know a lot of very useful very well done code that is not kept in any vcs.
Comment by jlebl — February 1, 2012 @ 7:51 pm |
Then, I shall respect your point. It’s like C vs C++, C++ vs C# or any language vs any other language: why the heck would I worry about performance on a script to the point that I make it on C? Why the hell would I want to make a driver on an Object Oriented language? And the list goes on.
Comment by Yuri Albuquerque — February 1, 2012 @ 8:42 pm
I agree with your article 100%. I see GIT as a cult as well, it’s like the Apple product of repositories. I am currently working on a project with a younger developer and introduced him to CVS over GitHub and it has been working out really well. Git adds so many steps to perform a simple task and you are right, if there is human interaction in a process, in this case synching up code, most of the time speed increases are meaningless. This is especially true abut GIt since it adds some many more manual steps. I don’t know, maybe I am just a crappy coder that cannot generate gigs of code in a few hours in order to see the benefits of Git 😛
Comment by Erick Rosas — February 13, 2012 @ 4:28 pm |
I have 2 features of git that I love:
1. git rebase -i -> this means that you can modify the history. It’s a bit of a sharp knife, so it can cut your fingers off, but you can have a great clean history if used with care.
2. git bisect -> let’s say you introduced a regression. Somebody who is using your code comes and says “It used to work on tag XXX and it’s not working anymore”. That you can kindly ask the user (tester at this point) to do a git bisect and test for the bug until he can pinpoint the commit that created the regression. This is priceless!
One side effect of using git is that it changes the way you think about commits. It will take more time to nurse the git history, but it will save your time in moments when you are totally clueless when and where a but appeared.
Comment by edgar grimberg — March 19, 2012 @ 12:07 pm |
First, I am super impressed that this post is still getting comments after 3 years. Kudos.
There are two reasons the post rubs me the wrong way, and in both cases, I see my father-in-laws ugly mug.
My father-in-law recently “upgraded” (it’s 2012 folks!) to, get this, Windows 95! He is using the same computer he was back in about 1992, but I’m not sure how he managed to get his hands on a copy of Windows 95, probably from someone with more sense then him. His excuse for being so far behind? “DOS does everything I need to do!” He only upgraded to Windows 95 so he could get this new (dial-up) Internet thingy. Your argument against Git echoes this same sentiment. “Why should I switch to Git when SVN does everything I need?” If your argument is valid here, so is my father-in-law’s. True, you can do source control with SVN, but you can do so much more with Git.
The second sentiment plaguing your argument is one of my biggest pet peeves, and that is, “It’s. Too. Hard!” (said with a whiney tone) Yes, there are more commands you will use with Git than you will with SVN. Yes there’s a steep-ish learning curve. As with everything else, however, it’s not hard once you learn it. “I don’t want to ride a bike! It’s. Too. Hard!”, “I don’t want to learn to drive! It’s. Too. Hard!” Is it? Really?
I do appreciate your passion, though. And really appreciate all of the git tips scattered throughout the comments.
Peace!
Comment by Joe Kueser — July 30, 2012 @ 11:11 am |
Well, I do understand git does more. It just does more than vast majority of people need. Just because something is new and does more things doesn’t mean it makes sense to start using it. For example I could buy a new bike with all kinds of new doo dahs, but the one I have had for the past decade does exactly what I need. I use zsh and vim. I use latex. All of these are very old and work really well. The only reason for switching to something different is that it does something that you need or want. Being new is totally irrelevant.
If the same computer that he’s been using since ’92 is still working and does what he needs. Then great! The thing is that for the past few years I haven’t been able to do “new” things on the computer. Only it has more glitzy effects and webpages got more complicated (not for the better generally). But functionally, all the things possible today could be done 5 to 10 years ago (at least the client side) if you remove some uneccessary nonsense.
Comment by jlebl — July 30, 2012 @ 7:57 pm |
I completely agree that you shouldn’t use something because it’s new and shiny. I’m a huge believer in using the right tool for the job, which used to make me a little unpopular with some team mates. When a new project came along, I wanted to take the time to figure out what the right tool is, and use is, while they wanted to jump right in with the stack they knew (at the time Java, Spring, and Hibernate). So I say all that to say this, understand your options, understand the pros and cons of your tools, and select the best tool for the job, each time. Don’t pick a tool just because you know how to use it.
In my case, Git is the choice most of the time for one primary reason: speed. As an example, I recently moved a project from CVS to Git. It is a medium sized project, not too big. But doing a simple “cvs update” took about 3 minutes. Now, being a good little developer, I update and commit several times a day (no worries if my machine crashes in the middle of the day, and this makes working with co-workers a breeze). On an average day I spent a total of about 30 minutes waiting on CVS. Git, on the other hand, takes about 5 seconds per update. So I regained 29 minutes of productive time by switching to Git.
Any time I am waiting on my computer instead of the other way around, I see it as a time to reevaluate my workflow or tool set. In this case, the productivity increase was well worth the learning curve. Especially when we can to the same for everyone on the team.
I guess it’s also worth mentioning that I work on a team that Git was designed for. We are highly distributed, in 5 cities across 5 timezones. But I can see situations where Git might be overkill…I just don’t believe that that percentage is quite as high as you think.
Comment by Joe Kueser — July 30, 2012 @ 8:29 pm
I never had cvs take 3 minutes on anything I use unless the network was totally broken. Anyway of course it’s the right tool of the job. I just believe that majority of jobs are small enough with few enough developers that it makes no sense to use git, especially if you already have cvs set up.
A friend who’s a professional chef told me recently that a “professional” is somebody that gets the job done with whatever tools he finds or has (he was saying this as he was cleaning the grill with a some sort of bent metal thing which was the first thing he found and which was hardly the correct tool for the job).
Comment by jlebl — July 31, 2012 @ 7:14 am
I like the version numbering for each file in CVS, it’s very clear to me. eg: Version number of file-a is 1.9, file-b is 1.23, if i edited file-a and commit it, it won’t affect version number of file-b, that’s very good for me.
Comment by LiuYan 刘研 — August 15, 2014 @ 9:48 am |
I like the version numbering for each file in CVS, it’s very clear to me. e.g: Version number of file-a is 1.9, file-b is 1.23, if i edited file-a and commit it, it won’t affect the version number of file-b, that’s very good for me.
Comment by lovetide — August 15, 2014 @ 9:54 am |