SVN Tools
Pages: 12
| rapidcoder: If they are using SVN, Perforce or Clearcase, it means they have poor software development process, |
Last edited on
@kbw maybe you should learn a real programming language and then come back to this community, exasperated to find how ignorant we are compared to you.
You should also demand to be paid 3x more because of how ignorant your company is.
You should also demand to be paid 3x more because of how ignorant your company is.
Last edited on
| L B: @kbw maybe you should learn a real programming language ... because of how ignorant your company is. |
Last edited on
I was sarcastically referencing rapidcoder ;)
Also, protip: [quote=username]
Also, protip: [quote=username]
Last edited on
closed account (S6k9GNh0)
You know, ironically, one of the most highly respect C++ library sets around (Boost) uses SVN. Although most do not like it... Speaking of which, most don't like how it's built or how anything surrounding boost works.
Last edited on
closed account (1yR4jE8b)
| That's not really relevant in a thread about SVN Tools. |
SVN is bad, and everyone who uses it willingly should be publicly shamed. Don't agree with me? Then you are ugly and stupid.
| You'd trust a Microsoft version control system? I don't think that even they use their own VCS software. |
They are *integrating* git, not re-implementing it. And they do have their own VCS software, called Team Foundation Server -- I even mentioned it in my first post.
| You don't always have a choice. Not all software is this free beer open source stuff. |
Using "no tool" is always free.
Having no version control over SVN or Perforce is frankly idiotic and damn near impossible to have more than two people working on the same project.
closed account (1yR4jE8b)
Tell that to Linus Torvalds who basically only used emails, tarballs, and diff/patch to develop the Linux kernel for many years before switching to Bitkeeper. At a talk at Google he said he would prefer going back to that than ever using CVS or Subversion ever again, and I tend to agree with him. Using Subversion has caused nothing but headaches for me in every single project I have ever worked on that has used it -- and I do understand how to use it; it's just a very very bad tool. I would rather use nothing than touch SVN/CVS, hell even Perforce or Team Foundation Server, ever again. Luckily, Git and Mercurial exist.
I've been monitoring this thread because I'm interested and want to implement some single-user version-control at home on my new Linux box for the revision history.
While I don't really have much experience with anything else, Tortoise SVN is working great at my company with 30+ developers on the same project. I don't understand the hate here. I also can't imagine it being any more streamlined.
Here's our process:
1. Check-out the repository from the central server (our automated nightly build machines to fresh checkouts every night). Update once a day (or more).
2. Develop
3. Check in your changes once you've tested your change.
As for features:
- I use Commit-monitor to instantly see what people have committed and whether I should update.
- I always keep my tree green (I don't keep local changes for extended periods). Tortoise overlays icons so I can easily see what is per repository, what's local, and what's conflicted.
- If someone has been working on the same file, an update will automatically merge it.
- I can see differences from each revision to find where a bug was introduced.
- I can "blame" the file which will give me the latest revision number, name of author, and commit comments for each line of code in a file.
- I can manually review changes from a merge and take action if required.
- If I update and someone else was working on the same line of code, It throws a conflict which I can resolve locally and then check-in when everything is good.
What does Git do that isn't listed? What's missing in this process? If there's an applicable advantage to Git over my familiar SVN, then I'm happy to make the switch at home but I haven't heard anything concrete here other than: it's very bad, SVN sucks, Linus doesn't use it so it can't be any good.
The only times I have troubles is if I am making a major change to every file in the repository. In that event, I can lock the repository to prevent the repository from constantly changing.
I could maybe see the SVN limitation if everyone is working on all files at the same time all of the time, but since this is an organized company and not just a group of non-communicating, unorganized FOSS developers, everyone has their own areas and maintains their own files for the most part.
While I don't really have much experience with anything else, Tortoise SVN is working great at my company with 30+ developers on the same project. I don't understand the hate here. I also can't imagine it being any more streamlined.
Here's our process:
1. Check-out the repository from the central server (our automated nightly build machines to fresh checkouts every night). Update once a day (or more).
2. Develop
3. Check in your changes once you've tested your change.
As for features:
- I use Commit-monitor to instantly see what people have committed and whether I should update.
- I always keep my tree green (I don't keep local changes for extended periods). Tortoise overlays icons so I can easily see what is per repository, what's local, and what's conflicted.
- If someone has been working on the same file, an update will automatically merge it.
- I can see differences from each revision to find where a bug was introduced.
- I can "blame" the file which will give me the latest revision number, name of author, and commit comments for each line of code in a file.
- I can manually review changes from a merge and take action if required.
- If I update and someone else was working on the same line of code, It throws a conflict which I can resolve locally and then check-in when everything is good.
What does Git do that isn't listed? What's missing in this process? If there's an applicable advantage to Git over my familiar SVN, then I'm happy to make the switch at home but I haven't heard anything concrete here other than: it's very bad, SVN sucks, Linus doesn't use it so it can't be any good.
The only times I have troubles is if I am making a major change to every file in the repository. In that event, I can lock the repository to prevent the repository from constantly changing.
I could maybe see the SVN limitation if everyone is working on all files at the same time all of the time, but since this is an organized company and not just a group of non-communicating, unorganized FOSS developers, everyone has their own areas and maintains their own files for the most part.
Last edited on
Torvalds' own presentation of git:
http://www.youtube.com/watch?v=4XpnKHJAok8
I think he does address the differences between git and svn.
I think all that you list is done perfectly by svn (I am an svn user myself). Although your team is huge by my standards, let me note that it is tiny by Torvalds': I think git was designed to (and does in practice) handle teams of 1k+ developers.
You are neither fair nor correct here.
http://www.youtube.com/watch?v=4XpnKHJAok8
I think he does address the differences between git and svn.
What does Git do that isn't listed? What's missing in this process? |
I think all that you list is done perfectly by svn (I am an svn user myself). Although your team is huge by my standards, let me note that it is tiny by Torvalds': I think git was designed to (and does in practice) handle teams of 1k+ developers.
a group of non-communicating, unorganized FOSS developers |
You are neither fair nor correct here.
closed account (1yR4jE8b)
Stewbond, have you ever tried branching/tagging/merging with SVN? That's where the real power of Git is. These tasks are an absolute nightmare with SVN (well, most centralized systems I've tried in general), but smooth as silk with distributed systems like Git and Mercurial. For example, if you've ever wanted to develop a new feature alongside mainline development and integrate the changes at a later date when the new feature is ready, with SVN it's very difficult but Git makes it extremely easy using Git's efficient branching and merging operations. Other version control operations are also extremely quick with Git because it never touches the network unless you are pushing/pulling changes between developers -- everything in SVN is dog slow in comparison because it's bottlenecked by the network connection.
Have you ever tried updating your tree with changes from 1000+ files at once with SVN? It takes a damn long time, but with Git it's practically instant. God forbid the system that is hosting your SVN repository dies, say goodbye to your entire project history -- hopefully someone has an up-to-date tree to start again from scratch...but with Git everyone has the entire history of the project on their own machine so there is no single-point-of-failure *ever*.
The benefits of distributed systems over centralized systems are numerous. I could go on and on and on about it.
Have you ever tried updating your tree with changes from 1000+ files at once with SVN? It takes a damn long time, but with Git it's practically instant. God forbid the system that is hosting your SVN repository dies, say goodbye to your entire project history -- hopefully someone has an up-to-date tree to start again from scratch...but with Git everyone has the entire history of the project on their own machine so there is no single-point-of-failure *ever*.
The benefits of distributed systems over centralized systems are numerous. I could go on and on and on about it.
Topic archived. No new replies allowed.
Pages: 12