There area a lot of point to catch up on here, but what I can say right now is that we successfully used Sourcesafe to manage branches over ten years ago in a product that is sold to the world's major aerospace companies. The criticisms may or may not hold up, but my experience was that Sourcesafe was as good/bad (there's no way of measuring these things) as the competition at the time.
― Keith, Saturday, 26 July 2008 02:40 (fourteen years ago) link
I'll read it more tomorrow, but the term "distributed" seems very weak. As far as I can tell (so far), it's technically the same as other source control systems but enforces some kind of meritocracy on development.
To me, distributed would just mean "client-server", e.g. if I do a diff, instead of getting the two files to my computer and diffing them, it would diff them and send me the result of that diff.
― Keith, Saturday, 26 July 2008 02:42 (fourteen years ago) link
I would have to say that now that I've read this stuff through more clearly, I still can't quite figure out what fundamentally the difference is; well, at least to the end user.
Let's assume SourceSafe has some problems. I wouldn't choose to use it. My point really was that for all the time I used it, compared with all the time I used CVS, there were just as many problems. Still, they are all about as bad as they get for source control systems. What I'm interested in is if there are some things that are lots better. For me, all Subversion really does that I like is use transactions to do commits, so I know that either all of it will be committed or none of it will be, which I kind of like to know; at least what's in the source control system is consistent.
I've never used ClearCase myself, but it's certainly widely deployed. I've done an interesting job of avoiding it. CM Synergy has an interesting model, but by all accounts in practice it doesn't work very well.
"Not being Subversion", I don't buy as an advantage. You'd have to explain why just being Subversion makes it bad (or worse, or whatever).
Now on to the key stuff... That Wikipedia article is extremely poor. What I was looking for are advantages and disadvantages, but the quoted advantages either seem to pretty much apply to the likes of CVS too, or they are not really an issue (e.g. 'allows private work' - my amazing hard drive allows me to do that!). The disadvantages are even worse - they aren't actually disadvantages of these type of SCM tools; they say (several times over) that the reason people don't use them is because they're stupid or intransigent.
Now, I may soon push for us to make a change from CVS at work. It's a big undertaking as there are 500 or so developers, but CVS really isn't cutting it these days, and I'd like to move to the right thing. Subversion is the most likely choice at the moment, but I'd love for someone to convince me that something else is a better thing to do, but that Wikipedia article seems to be extremely thin on facts.
― Keith, Saturday, 26 July 2008 18:10 (fourteen years ago) link
Eh, Subversion. I'm boring.
― Allen, Friday, 1 August 2008 15:11 (fourteen years ago) link
The Ruby guys here really love the (local) branch model of git. "Every new feature is a branch" Being able to change branches within a working copy is pretty great too. Check out github btw
― Catsupppppppppppppp dude 茄蕃, Friday, 1 August 2008 20:53 (fourteen years ago) link
I don't understand how even with ancient source control systems that logically, every feature is a new branch anyway, I mean, by editing your files on your computer, you are basically creating a new branch. What's the difference? I must be missing something.
― Keith, Saturday, 2 August 2008 00:04 (fourteen years ago) link
For sure I think I must be genuinely missing something here. Normally I'm confident enough that it's just the industry talking toss, but here I can't see that this many people would praise something without there being some value, but I don't see it. Can someone explain?
― Keith, Saturday, 2 August 2008 00:05 (fourteen years ago) link
(e.g. 'allows private work' - my amazing hard drive allows me to do that!)
Yes, but git allows you to commit offline -- instead of yr repository being on a server, it's stored locally, so you can do everything you would -- branch, merge, commit, revert etc on your ownsome, and if you want it stored somewhere else, you push it up to them.
I prefer that to subversion because I can make my local sandbox a total pigsty without the "good" server copy becoming a mess as well. I imagine that'd be handy if you were dealing with lots of developers too -- they can have local branches, then merge back and push. Or other people can pull from their copies to work on their changes, etc.
― stet, Saturday, 2 August 2008 00:59 (fourteen years ago) link
There's a guy at work, who is a total genius, and his three questions are:
- So what?
- Who cares?
- Why now?
And what I can't figure about the being able to "commit offline" (which I'm not sure what means) I think I would ask the first two questions about. Can't you just not pollute the repository by kind of not committing?
― Keith, Saturday, 2 August 2008 01:04 (fourteen years ago) link
By committing offline, I mean you can be entirely offline -- no connection to the server at all -- and still have the full version control set of commands going on. When you commit, it's not sent to a remote server, it's just incorporated locally.
That's where it's different from polluting the repository simply by not committing: you can do lots of commits, reverts etc, but it doesn't affect anyone else or the repository (though there isn't really such a thing under git) until you push those changes out.
― stet, Saturday, 2 August 2008 01:23 (fourteen years ago) link
― Keith, Saturday, 2 August 2008 01:24 (fourteen years ago) link
Sorry. Just asking the question. What's good about that? How does it make it so much better?
The guy who asks these questions reported to SD we were talking about earlier... He's a switched on guy.
― Keith, Saturday, 2 August 2008 01:25 (fourteen years ago) link
Well, under subversion if you're not polluting the repository by committing, you're left to basically do your version control by hand -- if you don't commit to the server, your changes aren't being stored so you can't revert. With git you can snapshot your state at any time, revert to it, and so on, all in private. xp
― stet, Saturday, 2 August 2008 01:27 (fourteen years ago) link
Oh OK, assuming your development environment doesn't let you roll back stuff, then that would be true. I suppose Deano doing vim development would appreciate this.
― Keith, Saturday, 2 August 2008 01:30 (fourteen years ago) link
and all the RoR/Textmate crew :)
― stet, Saturday, 2 August 2008 01:31 (fourteen years ago) link
That's true. There are lots of tools that would help them out.
― Keith, Saturday, 2 August 2008 01:32 (fourteen years ago) link
But I suppose it would result in just developing the same things but in a different place. It probably is inevitable. I've come to conclude that people don't learn from history.
― Keith, Saturday, 2 August 2008 01:33 (fourteen years ago) link
Automatic thread bump. This poll is closing tomorrow.
― ILX System, Tuesday, 5 August 2008 23:01 (fourteen years ago) link
Automatic thread bump. This poll's results are now in.
― ILX System, Wednesday, 6 August 2008 23:01 (fourteen years ago) link
version control is ~great~
― caek, Monday, 21 May 2012 18:29 (ten years ago) link
> I suppose Deano doing vim development would appreciate this.> ― Keith, Saturday, 2 August 2008 01:30 (3 years ago)
you what what?
― koogs, Tuesday, 22 May 2012 21:04 (ten years ago) link