"revision control system" for the beginner - Page 1
Forum section: electronics / general

author: george graves
author_rank: Super Contributor
timestamp: January 07, 2012, 01:19:45 am
content: Dave - I know you must have some insight into this...How about a blog post on "revision control system" for the beginner. Ya know - just how to keep track of all your revisions, and files, and projects (perhaps something local - rather than a git-hub type of thing)

author: IanB
author_rank: Super Contributor
timestamp: January 07, 2012, 01:51:58 am
content: That's software, not hardwareYou could take a look at Subversion though, if you want something simple and easy to set up...

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 02:03:58 am
content: Quote from: IanB on January 07, 2012, 01:51:58 amSecond this.Subversion plus TortioseSVN for windows is a great combination. Nothing on Macs or Linux comes close to TortoiseSVN unfortunately - they try and fail miserably. Since TortoiseSVN includes Subversion, that is all you actually need:http://tortoisesvn.net/downloads.htmlGet the 32 bit version, not the 64 bit version even if you have 64 bit Windows. Tortiose integrates with Windows Explorer and also the best File Manager, Totalcommander (No limitations except buying it removed the startup nag screen).Everything is done by right clicking in the file manager - you never start a program called "TortioseSVN".It is remarkably easy once you get the hang of it. At the start, it can sound confusing - typical programmers documentation.Subversion will handle any type of document fine including PDF's, images, binaryfiles - whatever you throw at it.If you talk to programmers, they praise git, etc and tend to rubbish Subversion, but for a system to run at home from a single repository (that is dead easy to back up), Subversion is the way to go.If anyone wants some simple instructions to get started, let me know.Richard.

author: george graves
author_rank: Super Contributor
timestamp: January 07, 2012, 07:19:14 am
content: Subversion looks interesting....but I think that might be a bit overkill to start out with. I was thinking more along the lines of good practices of file naming, and documentation, etc.

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 08:34:43 am
content: Quote from: george graves on January 07, 2012, 07:19:14 amMy experience is that using SVN (Subversion) makes it easier to manage, easier to backup, and nothing gets lost. In SVN nothing ever gets deleted in reality. If you delete a file, it disappears, but it is still in the repository.When you have done some work, you just right click on a parent folder and select commit. Tortoise SVN will find every new file or updated file and commit it. You can add a comment that describes your work.The repository itself means you don't have to start at the Head. If you are working on one bit of the work, you check out that bit only.The big thing is you do not use it the way the manuals seem to be describing.You make as many repositories as you want - never put too much in one repository. Just think of a repository as a super zip file - it is a package. You forget about all the Trunk/Branch stuff. Just make a new empty repository, grab the start folder of a project, commit it the new repository and that's the hard work done. It is dead easy after that.Managing repositories is super easy. SVN uses a database engine, but management is much easier then databases. You want to use an archived repository? Just copy the repository files for the archived project into the current repository location and checkout the files and folder you want.I have my SVN linked to a WEBDAV webserver which means that every repository and every file in each repository can be access through a browser. I can view or download files.You can come up with a system to manage files, but all such systems are always more complex then using SVN, as long as you have all the tips for using SVN correctly. With manual systems, you end up making lots of copies, so you don't wipe the old working copies. With SVN, you usually do not have to worry about keeping copies, and the other thing SVN can do is to keep all the correct versions of files together.TortoiseSVN does transform Subversion into a wonderful program, but ultimately it is a choice. Not for everyoneRichard.

author: wkb
author_rank: Super Contributor
timestamp: January 07, 2012, 09:56:25 am
content: Quote from: george graves on January 07, 2012, 07:19:14 amSVN might look like overkill but it sure does the job. CVS would also do it for you I imagine.Both VCS have been / are used by large scale projects, e.g. the FreeBSD Project uses SVN and (increasingly less) CVS.

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 10:03:54 am
content: CVS does not even come close to the ease of TortoiseSVN. It would be a pretty bad choice.

author: Bored@Work
author_rank: Super Contributor
timestamp: January 07, 2012, 01:14:36 pm
content: Quote from: george graves on January 07, 2012, 01:19:45 amDave has publicly stated he doesn't use one. Unprofessional, if you ask me, but that is his decision.Subversion is easy enough to use, even on the command line, that there isn't really an excuse not to use it. I still do have stuff stored in RCS and CVS, and in commercial systems like ClearCase (may the developers of this thing rot in hell ...), but for new stuff I turn to subversion by default.But it is really not so much what system you use, but that you use one, and not just as an alibi - i.e. not just one check-in once a month.There are crude systems I would recommend against. The just mentioned ClearCase is one, stupid git is another. But even these are better than nothing.

author: Rufus
author_rank: Super Contributor
timestamp: January 07, 2012, 01:50:30 pm
content: Quote from: amspire on January 07, 2012, 10:03:54 amErm TortoiseSVN was inspired by TortoiseCVS.

author: george graves
author_rank: Super Contributor
timestamp: January 07, 2012, 02:04:52 pm
content: Welll, since I've suggested it twice, how about we rope this thread in to talk about things other then "revision control" pro stuff - and talk more about it on the noob level. K? Thanks.

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 02:28:16 pm
content: Quote from: Rufus on January 07, 2012, 01:50:30 pmI had forgotten about that, but I still think using CVS instead of SVN is nuts.CVS will be more work, and will not be as convenient.Quote from: BoredAtWork on January 07, 2012, 01:14:36 pm"Stupid Git" - is that its full name? Linus Torvalds will love you.Stupid Git is a purpose-built design tool - for collaborative software programming projects for people running Linux or other Unix spinoffs. The Linux Kernel programming in particular. If you are not a pure programmer doing collaborative projects, forget it.SVN can be used from the command line, but I do not recommend it. TortoiseSVN just does so many things brilliantly that SVN does crudely. It can check for all changes in a folder tree, and find what has to be added, what has to be deleted and what has to be committed. SVN command line, or most of the other SVN tools availabe do not do all this automatically. Even better, if the the TortoiseSVN operation fails, it can usually fully back out to where you were at the start. On commits, it shows you every operation it will do and you can manually unselect any of them. Nothing has actually happened until you click OK. From the command line, you usually have to do SVN ADD and SVN Delete commands before the commit, and if there is a problem, it is a pain undoing the Add and Delete commands. There is just no combination of SVN command line commands that can do what TortoiseSVN does with a few clicks of the mouse.

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 02:32:44 pm
content: Quote from: george graves on January 07, 2012, 02:04:52 pmSo instead of the fairly simple to use SVN, you want to talk about the more complex solution of trying to manage files manually?

author: george graves
author_rank: Super Contributor
timestamp: January 07, 2012, 02:46:53 pm
content: Quote from: amspire on January 07, 2012, 02:32:44 pmExactly! Files are so hard to manage.LOL - What you talking 'bout willis?If you would like to start your own thread - go ahead.

author: Bored@Work
author_rank: Super Contributor
timestamp: January 07, 2012, 03:18:18 pm
content: If you want predictable answers, and push people around so they do what you want just hire someone. What you get here is for free and voluntarily. If you don't like it go elsewhere.

author: wkb
author_rank: Super Contributor
timestamp: January 07, 2012, 03:20:35 pm
content: Quote from: amspire on January 07, 2012, 10:03:54 amCVS is not more difficult to use than SVN. Well, maybe on Windblowz it is..

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 03:31:20 pm
content: Quote from: george graves on January 07, 2012, 02:46:53 pmWhy would I want to start a new thread? You asked a question and we have answered. Do actually think that manually managing project files safely is easy? If you know something, let us in on the secret.

author: ndictu
author_rank: Regular Contributor
timestamp: January 07, 2012, 03:32:48 pm
content: CVS/SVN is pretty much dead in the software world. Just use something modern like git or mercurial. You can get free hosting on github/bitbucket, which will serve as a backup and if you make it public also allow people to contribute.On windows the tools are better for mercurial, use TortoiseHG, it's pretty much the same as the other tortoise tools.You guys seem to dislike git/mercurial because it's not "local". That is not true. You can use both without any kind of remote repository. You don't need to even run a local server. All you need is to create a local repository with TortoiseHG and use it.But why wouldn't you push the changes to a free remote repository? It's a backup plus a collaboration tool. But you don't have to...

author: IanB
author_rank: Super Contributor
timestamp: January 07, 2012, 05:28:09 pm
content: Quote from: ndictu on January 07, 2012, 03:32:48 pmWell the difference between using some kind of revision control system and no system at all is like night and day. When you are using a system to manage your personal work with unsophisticated requirements, it doesn't matter so much whether you jump on the latest bandwagon or not. Differences that matter to large teams and big projects matter less to the individual who just wants something simple and easy to use.I have to say that in the professional world git or mercurial are not predominant any more than SVN. Open source tools get used by people with smaller budgets, but they rarely win out over commercial offerings when the commercial offerings are considered by organizations with budgets to afford them.To get back to what George was saying, any attempt to manage revisions and versions of evolving files manually is a nightmare compared to using even one the oldest and most basic tools like CVS. SVN is a good choice for someone starting out. With nothing at all you just don't know what you are missing.

author: DavidJRobertson
author_rank: Regular Contributor
timestamp: January 07, 2012, 05:43:28 pm
content: I really must recommend using a distributed version control system. This means that there doesn't need to be a central server, and makes collaboration easier.I like to use Mercurial, although Git is a very popular choice. I think Mercurial is a bit easier to use than Git.And never underestimate how useful sites like github.com, and bitbucket.org are.

author: ndictu
author_rank: Regular Contributor
timestamp: January 07, 2012, 06:20:15 pm
content: Quote from: IanB on January 07, 2012, 05:28:09 pmI agree with that, in the sense that if you already are using something and don't need more, there is no need to change systems. But if you aren't using anything and want to start, it would make sense to start with the modern technology instead of the outdated one.Quote from: IanB on January 07, 2012, 05:28:09 pmNot sure if you mean HW or SW world, but in software development pretty much everyone switched to DVCS long time ago. But then again, there are companies that use the copy-and-zip method, or no revision control at all.So, if you are using CVS/SVN, and are happy with it there is no need to switch.If you want to start using something, you might as well start with git/mercurial. In any case, try out few alternatives and find what fits your needs the best.

author: wkb
author_rank: Super Contributor
timestamp: January 07, 2012, 06:37:31 pm
content: Quote from: ndictu on January 07, 2012, 03:32:48 pmSVN has largely replaced CVS, ok. SVN dead? Bollocks..

author: Unknown
author_rank: Unknown
timestamp: January 07, 2012, 06:38:49 pm
content: There's a free book (you can order the dead tree version for free) available on this topic. It's focused on command line use and is written by a software developer, but revision control is revision control, regardless of what you store in it. Here's the link:Version Control by Example.I don't think Dave is the right person to talk about revision control, I'd rather have him talk about stuff he knows.

author: IanB
author_rank: Super Contributor
timestamp: January 07, 2012, 07:21:09 pm
content: Quote from: ndictu on January 07, 2012, 06:20:15 pmI said "open source, like Git and Mercurial", you said DVCS. That's not the same thing. There are more choices out there for source control than Git and Mercurial, even if they get talked about a lot within a certain community.What I really said was that big, commercial organizations are likely to choose commercial systems like ClearCase or TFS. In large parts of the professional software world Git and Mercurial are mere curiosities, sideshow attractions to be looked at in passing but not seriously considered.

author: ndictu
author_rank: Regular Contributor
timestamp: January 07, 2012, 08:31:15 pm
content: Quote from: IanB on January 07, 2012, 07:21:09 pmYeah, OK... There are big businesses that use all kinds of commercial stuff. The reasons are probably great (paid) support 24/7, integration with their internal systems, or even management people who don't understand it making the decision ("That one is free, this one costs money - clearly it must be better!").In any case ... for personal use, small teams and large opensource projects (and even large corporate use, in case you can get everyone to switch), there is nothing wrong with the OSS tools.As I said:Quote from: ndictu on January 07, 2012, 06:20:15 pmAlso, this seems to be turning into a little flamewar. So I'll just link my favorite tutorials and let it be.http://tortoisehg.bitbucket.org/manual/1.1/quick.htmlhttp://hginit.com/

author: IanB
author_rank: Super Contributor
timestamp: January 07, 2012, 09:08:13 pm
content: Quote from: ndictu on January 07, 2012, 08:31:15 pmI didn't say there was. It's a big world out there with many different situations, many needs, many options. Any given choice may not be right for everyone. The only mistake you can make is to over generalize.

author: amspire
author_rank: Super Contributor
timestamp: January 07, 2012, 11:05:11 pm
content: Quote from: ndictu on January 07, 2012, 03:32:48 pmI don't hate mercurial, git or bazaar. I have used Subversion extensively, and I know it works well with much more then software files. I know how to make it work brilliantly, and I have a a 3 year track record of extremely intensive use so I know I can trust it. I have used it with animation projects where single commits can be 1GByte plus, and files can be 500MBytes. It is solid, and the inclusions of the .svn folders in the checkouts, though being a pain, have had far more positive consequences then negative. Once you get away from programming, merging becomes almost useless, along with workflows based on merging.Distributed versus centralized repositories ? Distributed works brilliantly sometimes and fails miserably in other cases. Centralized means there is a single bottleneck and a point of failure, so you have to plan for that. When it dies, everything comes to a stop.Can the newer repositories cope as well with file structures that look nothing like programming projects as well as Subversion? Perhaps they can, but it would take me something like 6 months of heavy use with many GBytes of files to establish a trust. What I do know is if you try and find out on the internet, all you can find is is opinions from programmers and their concerns.I don't have a current Mercurial checkout on my PC, but I have a Bazaar checkout, and it looks like it does not have the equivalent of the .svn folders. It probably would be a nightmare for animation files.A quick look at the mercurial repository structure shows that it controls the state of the working directories from the repository. One of the huge strengths of SVN is it doesn't case less about the state of working directories. You can move them anywhere, zip them up, put them on a different PC and they work fine. With the way I have SVN set up, I can unzip a working checkout on a different network at a different location and it still works perfectly. Mercurial has a command to clone a repository. In SVN, you can just copy a repository to a new folder and it will work fine. But if anyone has used any of the alternative newer generation repositories extensively for general files and huge commits, I would be interested.The people who praise git, mercurial and bazaar seem to be hard core programmers. They are concerned about programming workflow issues. We are engineers, and our files can be anything, including programming files.Richard

author: Unknown
author_rank: Unknown
timestamp: January 07, 2012, 11:32:53 pm
content: Quote from: amspire on January 07, 2012, 11:05:11 pmMost revision control systems allow you to specify an external merge tool, like the compare document feature in Microsoft Word. I believe something similar is available to merge Labview files. Though merging may not make sense for all document types, the fact that it's not a text file doesn't automatically make it impossible to merge.Quote from: amspire on January 07, 2012, 11:05:11 pmCentralized repository is essentially a subset of distributed repositories. Just treat one of the repositories as the master and treat the other repositories as working copies. You get the advantages of distributed development like offline commits and better performance while retaining a single master version. This is how git is used by the Linux kernel developers. Linus's repository is the master version.Quote from: amspire on January 07, 2012, 11:05:11 pmI believe some story binary deltas like Subversion. Some (I think it was Mercurial) expect the history of a single file to fit into memory, the book I linked to earlier has some information on this.Quote from: amspire on January 07, 2012, 11:05:11 pmAll distributed revision control systems carry the complete repository in a subdirectory of their 'working copy'.Quote from: amspire on January 07, 2012, 11:05:11 pmYou can freely copy and move them around. The advantage of using clone is that it may be more efficient. It may use hard links to share objects between the repositories to save space. It also sets up the origin repository so push/pull will access the source repository. Clone can also transparently clone network repositories. None of the common DVCSs play weird tricks with inodes that prevent cause problems with copying.

author: amspire
author_rank: Super Contributor
timestamp: January 08, 2012, 12:31:46 am
content: Alm,Thanks for the great information. I am getting the book you linked to now- it could be very interesting.Looks like I might have to bite the bullet and start testing some of the newer repositories, but it is a lot of work. It is not just a matter of learning it, and working out how to configure it to work at least as well as Subversion. The more important step is then to do long term tests to verify it is reliably, particularly with difficult files. The biggest nightmare is the repository that you can no longer recover your files from. Subversion though does definitely have rough edges and something better would be good.Your description of cloning was very clear. The links from a clone repository to the source is definitely something that in general I would want to stay clear of, except in the case of a short term temporary repository. That is something to investigate in more detail if I try out Mercurial. I want each repository to be totally complete and have no dependency on any other repository.Anything that cannot cope with huge commits and huge files without requiring equally massive PC memory will probably be a non-starter for a general purpose file repository.Richard

author: AntiProtonBoy
author_rank: Frequent Contributor
timestamp: January 17, 2012, 05:03:55 pm
content: Personally I rate Git derived repos, mainly because I'm a programmer.Having said that, I'd avoid using Git for any project that contains a lot of binary file formats.Git doesn't do binary diffs.

author: Unknown
author_rank: Unknown
timestamp: January 19, 2012, 09:26:06 pm
content: Quote from: AntiProtonBoy on January 17, 2012, 05:03:55 pmWhere did you get that information from? Git does delta compression just fine for binary files, its internal format does not care about binary vs ascii. It will also compress the deltas. Use git diff --binary if you want to generate a binary diff you can send to someone else for use with git apply. Only merging requires an external merge tool. Of course how well binary delta work depends on the details of the format, anything involving compression will be very inefficient, for example.The only limitation is that it won't delta files above a certain threshold (512 MB by default) because that would require excessive memory, at least if you use fast-import.

author: AntiProtonBoy
author_rank: Frequent Contributor
timestamp: January 20, 2012, 01:10:10 am
content: I'm my experience git simply synchronised entire binary files instead of deltas, even with the "diff --binary" binary command. Could be a specific issue on my windows install, or with the repo site, who knows. It was major pain when I had to work with textures and audio file assets.

author: ndictu
author_rank: Regular Contributor
timestamp: January 20, 2012, 02:46:31 pm
content: Quote from: AntiProtonBoy on January 20, 2012, 01:10:10 amThat depends on the file format and compression used. If you change the color balance or speed up some audio track the delta would basically be the same size as the file itself so it maybe didn't bother with it. Also if you have an encrypted file the high entropy will make it almost impossible to make a useful delta.

author: Unknown
author_rank: Unknown
timestamp: January 21, 2012, 01:43:40 pm
content: I would agree that this was probably down to the file format, and not git's binary delta algorithm, unless you got much better results with some other VCS. Compression will usually make binary deltas ineffective, unless you only change a header (like an ID3 tag in an MP3 file). Not much you can do about this except changing file format or putting knowledge about the specific file formats into the delta algorithm. For example, open document (eg. .odt) files are ZIP files with XML files in them. Diffing the XML files would work much better than comparing the ZIP files, and might even allow merging. Adding knowledge about XML files could make it even better, just like how FLAC and MP3 work better on audio than ZIP.

author: westfw
author_rank: Super Contributor
timestamp: January 22, 2012, 07:12:28 am
content: the OP didn't say much about his requirements...RCS is pretty much the grand-daddy of revision control systems, and for a individual user on a local system, going from "nothing at all", and using the command line of unix-style shells, it's a big improvement and probably sufficient.CVS becomes more important when there are multiple developers working on the same project.Other things become important when there multiple computers and clouds and things. I suspect there are now things that are more GUI-like and "modern." (bah humbug!) Git, mercurial, and svn all seem to have large segments of the open-source community singing their praises and cursing their failings. Personally, I pretty much pass over anything that starts with "first, set up your server", unless I plan to publish to github (which uses git) or google code (which I've seen use mercurial and svn.) I can do without adding "server management" to "revision management" (unless of course someone else is managing the project and/or server.)

author: george graves
author_rank: Super Contributor
timestamp: January 22, 2012, 09:17:38 am
content: Quote from: westfw on January 22, 2012, 07:12:28 amQuote from: george graves on January 07, 2012, 01:19:45 am.....oh well.

author: Unknown
author_rank: Unknown
timestamp: January 22, 2012, 12:26:56 pm
content: A typical distributed VCS like git or Mercurial does not need a server for local operations, and can use standard transports like HTTP or SSH. I wouldn't recommend RCS and CVS for anything but legacy applications at this point. The extra complexity of the modern replacements is minimal if all you do is commit and checkout, and there were some real problems that the newer generations fixed, like the handling of binary files.