CVS user can't come to grips with SVN versioning - Page 1
Forum section: electronics / general

author: AlfBaz
author_rank: Super Contributor
timestamp: August 01, 2013, 03:43:35 am
content: I know this is an electronics forum and predominantly versioning is related to software source, but historical notes during development, changes, releases etc of hardware design is also handyFor example I recently completed a project that started off with a PIC32, XILINX fpga and ddr ram and ended up with an arm processor minus the fpga. I then wanted to do another project with a pic32 and an fpga for something completely different and I just checked out the old version and branched off of thatI have used cvs in conjunction with tortoise for quite some time and on a recent reinstall found that these March Hare dickheads have ruined what I believe was a great open source versioning system... A bit of reading about the situation leads me to believe they may well have violated the original GPL license but as everyone has moved on to svn nobody seems to give a tossAnyhow, I decided to look at svn since it seems to be the major versioning system for people messing around like me and I just can't seem to come to grips with this "tree" versioning rather than file versioning.With cvs a particular files' version number and comments are exclusive to itself where as svn bumps the revision number on every thing in that project.The way its explained in the svn manual is that its no proper to say version 5.0 of file foo.c but rather how foo.c looked in version 5.0 of the project. I find this weird.What I'm posting here for is to get peoples opinions, stories etc and hopefully I'll come away with an "ahh, OK that makes sense" moment

author: Dago
author_rank: Frequent Contributor
timestamp: August 01, 2013, 05:12:12 am
content: Git is by far the best VCS. Really common as well, especially with GitHub nowadays. We use SVN at work and I really dislike the "branch is a folder" -thing.

author: IanB
author_rank: Super Contributor
timestamp: August 01, 2013, 05:27:37 am
content: I used CVS way back in the 90s and a lot of water has passed under the bridge since then. I think we might call CVS ancient or historic these days. SVN certainly seemed like an improvement, though I have not used it much, and I think even that is old today. I think in SVN each file still retains its own revision history, but there is an idea that you are managing a project as a whole rather than a loose collection of files.If you went back in time before CVS you would find RCS, which quite literally did manage individual files one by one.When I did use SVN I found it very intuitive. I could check out one or more files for editing and then check them back in again with new version numbers. You may be confusing release versions on the project with revision numbers on files. Files in SVN still have revision numbers just like CVS.In the modern world people seem to be using Git (I have not used it myself though). If you need to make a jump from CVS, it may be worth getting right up to date.

author: ajr
author_rank: Newbie
timestamp: August 01, 2013, 05:45:35 am
content: Before you waste a lot of time on Git, look at Mercurial first. A lot easier to start with, but essentialy the same features. And bitbucket is much more usefulll than github IMHO (private repositories for example).Disclaimer: I know how to use Git, still like Mercurial more.

author: c4757p
author_rank: Super Contributor
timestamp: August 01, 2013, 06:07:47 am
content: I think both are quite good. I use Git out of habit but have been quite happy with Mercurial before. Either way, you can't go wrong.Subversion..... works.

author: sleemanj
author_rank: Super Contributor
timestamp: August 01, 2013, 06:21:03 am
content: Quote from: AlfBaz on August 01, 2013, 03:43:35 amSVN stores revisions as a diff applied to your entire tree, that's just how it is, in revision XYZ of the tree, your file foo.c looked like such and such, then you commited XYZ+1 which happened to include this diff to foo.c, now foo.c looks like so and so.In typical project management, you care about an entire project's state more than about some specific file, most of the time.You can still view the history of a single file (svn log path/to/foo.c) to see exactly which revisions changed that file, and you can see the exact diff to the file between revisions you are interested in (svn diff --revision XYZ:ABC path/to/foo.c).Git has gained a great deal of popularity, mainly I feel due to github, but I prefer SVN with a Trac setup as a tree browsing interface myself.PS: If you really want to play with your head, give Darcs a try!

author: Unknown
author_rank: Unknown
timestamp: August 01, 2013, 06:50:51 am
content: File versioning does not make sense for most projects in my opinion. If I moved foo() from a.c to b.c, it might be removed in a.c 1.11 and added to b.c in version 1.2. How am I going to find the corresponding versions a year later when I'm tracking down a regression that it introduced? You can sort of use the timestamp, except for the case with simultaneous commits. Remember what the C in CVS stands for?A version for the state of the whole tree, source files and header files, makes much more sense to me. And yes, SVN getting replaced by git and Mercurial, but be prepared for even more of a paradigm shift and to actually understand what you're doing instead of clicking pretty buttons.

author: casper.bang
author_rank: Frequent Contributor
timestamp: August 01, 2013, 07:11:42 am
content: Quote from: Dago on August 01, 2013, 05:12:12 amAs others have stated; the biggest difference between the two (CVS and SVN) has to do with atomic revisions of file vs. repository. In CSV (which In my opinion should NEVER be used in this day and age) you can very well experience a situation where only 50% of your files were committed. This means if you are in a hurry to get home from work, you have the choice between leaving the repo in a mess (your colleagues won't be pleased), or stay an extra ½h sorting out the conflicts and committing.If you are thinking of moving on from CSV, might as well look into distributed SCM's. They are a bit more complex to comprehend, but they also offer a lot of advantages. The biggest shortcoming of SVN remains how hard it is to work in branches, which HG, Git etc. solves beautifully.

author: John Coloccia
author_rank: Super Contributor
timestamp: August 01, 2013, 11:06:54 am
content: The best system I ever used was Accurev. You pay for it, but I've never worked with anything better and I put the whole office on it back when I had a real job. It gets a lot of negative press from people that want it to work like SVN. LOL. Accurev ROCKS.Yes, the SVN versioning is a good idea in theory, but it's incomplete and immature. My opinion would be to dump it before you get too far and get into Git or Mercurial, both of which are rather similar to Accurev in function, actually.

author: Rufus
author_rank: Super Contributor
timestamp: August 01, 2013, 01:42:21 pm
content: Quote from: AlfBaz on August 01, 2013, 03:43:35 amI gave up on Tortoise due to lack of x64 support, apparent lack of interest in supporting x64 and Microsoft removing some shell interfaces in x64 which is probably part of the reason for the other two.WinCVS works OK for me as a gui for CVS browsing and management.

author: AlfBaz
author_rank: Super Contributor
timestamp: August 01, 2013, 02:13:14 pm
content: Thanks for the input...I have a very limited use case of cvs, local repo and just me working on projects. I use it mainly for documenting and to that end it has been flawlessI'll read up on git. I presume you can have a local repository or you can store it in github should you need to go open source or collaborate with someone?Since I don't interact with "the industry" I still fail to see a convincing argument with regards to bumping rev numbers for unmodified files. Committing revision number worthy file states happens all the time where as end software releases should happen less seldom (if at all) so for me personally I prefer to have revision numbers for individual files that pertain to that file only, especially as I'm the only one working on them

author: Monkeh
author_rank: Super Contributor
timestamp: August 01, 2013, 02:21:31 pm
content: Quote from: AlfBaz on August 01, 2013, 02:13:14 pmYou're confusing repo revision with software version numbers..

author: IanB
author_rank: Super Contributor
timestamp: August 01, 2013, 02:27:52 pm
content: Quote from: AlfBaz on August 01, 2013, 02:13:14 pmThis doesn't happen. Files only get a new revision if you modify the file and check in the changes.

author: John Coloccia
author_rank: Super Contributor
timestamp: August 01, 2013, 03:07:35 pm
content: Quote from: AlfBaz on August 01, 2013, 02:13:14 pmThat's not really what happens. What happens is that when you commit changes, the state of the entire repository is also recorded and tagged...so yes, when you make even the most trivial change to any file, the entire thing gets bumped. This is a GOOD thing. Most projects have multiple dependencies. For example, a typical firmware project might have the software, the FPGA/CPLD configuration, schematics, artwork, documentation, etc. Within these, there are other dependencies. The software might have the dependencies on libraries that have previously been written to handle serial communications, interrupts, boot loaders, LCD screen comms, generic state machines, etc etc....So when you commit a file that you think works, it's good to know EXACTLY PRECISELY what state everything else in the system was in when it worked. Someone can make a tiny change somewhere....maybe not even working on your project, but maybe they downloaded a new version of a 3rd party library that your generic library depends on, and then you suck in that generic library and suddenly nothing works anymore.That's why you see so many times where code is reused but COPIED instead of linked. On smaller projects, this makes far more sense than to develop the infrastructure to test everything against everything else anytime a change happens somewhere.Anyway, that's one reason, and perhaps the most compelling reason, to rev the entire repository anytime a change is made.That said, Git and Mercurial are just far better. SVN is ancient technology and thinking, and it wouldn't exist if CVS hadn't had some serious flaws.

author: AlfBaz
author_rank: Super Contributor
timestamp: August 01, 2013, 03:20:53 pm
content: Ah ha. That makes sense. Now that I think about it I used to have add tags and commit all files changed or not when I had a working setup that would inevitably fail when I continued working on, or trying something new... a major pain checking that tagged version out. Good stuff

author: AlfBaz
author_rank: Super Contributor
timestamp: August 01, 2013, 03:24:23 pm
content: Quote from: IanB on August 01, 2013, 02:27:52 pmSo it keeps an overall "tree" revision number as well as individual file rev numbers?I think the best thing for me to do is just try it and see for myself

author: Monkeh
author_rank: Super Contributor
timestamp: August 01, 2013, 03:25:42 pm
content: http://svn.apache.org/viewvc/subversion/trunk/Browse through. It's pretty simple.Each revision contains a set of changes to one or more files.

author: MacAttak
author_rank: Unknown
timestamp: August 01, 2013, 03:43:55 pm
content: Quote from: AlfBaz on August 01, 2013, 03:24:23 pmNo, it keeps a list of "changesets" each of which has a unique identifier. Any modified files within that changeset share the same identifier (which functions as a "rev number" but it isn't necessarily a sequential number).Regarding the earlier question about local versus distributed... the way Git works is that you always have a local repository that you check in your commits to directly. You can then have  remote repositories that you may push those locally-committed changesets up to. When you use GitHub, that is what you are doing. But you can also use other distributed repository systems such as CodePlex, etc. Many now support the Git remote API.I worry though that if SVN is giving you a headache, trying to get a handle on Git might cause an aneurysm. Don't be fooled - learning a new VCS is not a trivial matter (doesn't matter which VCS). They all have their own vocabulary and different ways of accomplishing things. And sometimes it feels like they just move the cheese for the hell of it.

author: AlfBaz
author_rank: Super Contributor
timestamp: August 01, 2013, 04:04:51 pm
content: Quote from: MacAttak on August 01, 2013, 03:43:55 pmI'm trying to avoid a headache. When I first started with cvs it was on the command line and got to know it fairly well. I remember it was no picnic that's why I wanted to hear from others about the basics before diving into a new system only to realise it didn't suite me. As far as "moving the cheese" I'm starting to wonder why I'm changing a system that has served me well. I guess if I want to play with others I can't be pulling out my GI Jo and expect compatibility with an xbox