Free source version manager???
Community Forums/General Help/Free source version manager???
| ||
| Anyone know any free source version manager aka Visual Source safe or Sourcegear Vault?? Does not have to be advanced, its just for sharing source code with another. |
| ||
| SVN is pretty easy to setup, and if your on windows you cant get any better than TortoiseSVN as a client. |
| ||
| TortoiseSVN and www.assembla.com Assembla isn't free but its only a couple of $ a month with the added benefit of having an off-site repository, so no more "I couldn't finish my game because my hard drive blew up/house collapsed". |
| ||
| RCS is also useful :-) |
| ||
| Assembla isn't free but its only a couple of $ a month with the added benefit of having an off-site repository, so no more "I couldn't finish my game because my hard drive blew up/house collapsed". *Dabz hides behind the couch in shame* ;) Dabz |
| ||
| http://git-scm.com/ |
| ||
| git and svn are both cool. There are many others too. Some web hosts, like Dreamhost, actually offer svn as part of their service so you can get offsite storage for your code. |
| ||
| Thanks! |
| ||
| TortoiseSVN and XPDev all free |
| ||
| Check out Perforce. It's free for up to two clients and the best I've ever seen. SVN is simply crap against that. |
| ||
| Xaron: I've heard good things about Perforce and we're considering it at work. Can you explain what's so great about it. |
| ||
| ragtag: We use it actually at work (in a rather big company with ~1,000 employees). We've checked almost every version control system out there and Perforce was the winner. Our Perforce server is rocksolid stable with a size of several Terabytes now. It has a slightly different concept like SVN has. What I like (partly against SVN): - no hidden files and directories in the project folders - very nice graphical user interface and merge/diff tools - free for up to 2 clients - very good customer service - stable, just stable - checkins just give a new revision number to CHANGED files only not to the complete folder like SVN |
| ||
| Hmmm, don't really want to debate, but... -hidden files. Can't argue that, but it doesn't bother me. The nice thing it does do though is make your svn checkout directory portable. Meaning you can move it without it getting disconnected from its state against the server. -GUI. There are lots of good GUIs for SVN, since it is open source. Tortoise is a great one. -free for 2 clients. SVN is free for asmany as you want. -Customer Service. I have never needed Customer Service for SVN. It is pretty straight forward and easy to use. -Stable. I have never had any stability issues with SVN. What stability issues are there? -Revision number only to changed files? I am not sure that is a good thing. Is there also an overall revision number? With SVN, I know the state of ALL of the files at revision 356. But if the files themselves had revision numbers, then a build might have rev 7 of one file and rev 3 of another. That would be a pain to keep track of, I think. |
| ||
| I guess I'll do points for git 'cause that's the cool thing to do. • You have one 'hidden' directory (and inside of it are things you can customize, so it's not really hidden per se), versus SVN's terrible method of cramming one in every single directory. Note: in future versions of Subversion, this issue may be fixed, seeing as how there's no bloody reason to do it the way they are now. • GUIs are for sissies. Granted, on Mac OS you have stuff like GitX, but on Windows you're going to be treated like the dumb child who never figured out that he's using the kiddy OS and your needs will be ignored. This is just the nature of the beast, seeing as how it was made for Linux kernel development. Progress has been made, but you're still in a world of pain because you decided to use a system without any real POSIX compliance. • GPL. • There is a large community of people using git, and you can get your support from them if necessary. Downside is you have to be nice and can't just treat them like they owe you support. • git is stable as far as I'm concerned. Never had any issues myself, I've never really heard of other folks having issues. • This is a non-issue seeing as how revision numbers aren't counted last I checked. Could be wrong, but I've never seen them anywhere. Anyone who argues about the lack of revision numbers should sit back and think very carefully about whether or not they really needed them. Additionally, I hate Perforce. |
| ||
| You have one 'hidden' directory (and inside of it are things you can customize, so it's not really hidden per se), versus SVN's terrible method of cramming one in every single directory Which, for me, immediately gives it the thumbs up. |
| ||
| Nilium, if git does not have version number, then what does it use? Let's take this example: I am writing a piece of software, I sell it to a customer and I know they were given a build of revision 300 from the SVN Repository. Later when they need another copy for some reason, I know which build of the source to give them. I do not have to worry about keeping a copy of their build around somewhere else. I can just grab build 300 from the repository and compile it for them. This could be necessary if a later version requires a different configuration of some sort (database maybe) and you do not want to have to worry about upgrading a client who has an issue. Does that make sense? Does git give you no method to know a version of the software? |
| ||
| Revision number is not version number. If you are using it as a version number, especially in Subversion, shoot yourself now. Additionally, if you want to know which version you gave someone, tag that commit with the version number. Tag it with "I gave this to those poor saps." (Edit: This is how you're supposed to do it in subversion too- learn your tools) |
| ||
| LOL When you pull out a build earlier than the latest, you put the revision number. That is what I am talking about. You do not have to get upset. There is no personal attack from my side. I am just trying to understand. How do you identify an earlier revision to pull from the repository? |
| ||
| You use the SHA1 of the commit for that revision, or a tag you assigned to that commit. e.g., git tag -m "Version 1.5" v1.5 9c57090611 # later ... # regular checkout git checkout -f v1.5 # create a new branch when you do the checkout git checkout -f -b new_branch v1.5 # without tags git checkout -f 9c57090611 Fairly simple. The number of characters you use to refer to the SHA1 is mostly up to you- 5 to 7 is usually good enough. I'm not getting upset, although I suspect the way I write things tends to make people think that somehow. |
| ||
| So, you are labeling (tag) the repository at a certain spot. I see. I am sure it is possible to checkout from the repository from a spot in time that you did not tag though right? How would you do that? By date/time? |
| ||
| a build of revision 300 from the SVN Repository. Bad. if you want to know which version you gave someone, tag that commit with the version number. Good. This is an example of having tags in SVN : http://code.google.com/p/maxmods/source/browse/#svn/tags For any given release, I have a snapshot of the code available to me at that time. If I want, I can diff between that version and now, to see what I've changed since then. I don't care what the subversion number is/was. ...I suspect the way I write things tends to make people think that somehow. you think? :-) We use all kinds of version control at my work. The legacy stuff uses VSS, which is totally useless over our WAN. At least it is slightly better than PVCS. Although they both suck tbh. For my current work projects, I used Subversion. For the newest project I've recently got my hands on, it is currently using CVS. We're pushing to have it moved onto git, since we want to have local repositories on two sites that we can sync when required. Although getting the "old thinkers" to move onto something they haven't heard of is a tad painful... |
   |