Source Code Control
in [Embedded]
|
From: Peter on 8 Nov 2006 23:05 Tom Lucas wrote: > IAR reckons they support systems that conform to the Microsoft SCC > interface - does that include Subversion? Also Rowley's Crossworks > supports Microsoft Visual SourceSafe, SourceGear SourceOffSite 3.5.1 and > CVS so would I be right in assuming that Subversion would be OK too? As of a few weeks ago Rowley Crossworks for ARM didn't support SVN but, in their words, " It's on the todo list - can't give a schedule as yet." (15th Sept '06) peter
From: David Brown on 9 Nov 2006 03:03 David Kelly wrote: > In article <12l2p4fjevr47b(a)corp.supernews.com>, > Grant Edwards <grante(a)visi.com> wrote: > >> This bit is particularly ominous: >> >> The most common reasons for data corruption are: >> >> * General network problems, for example, an unreliable >> remote connection causing Visual SourceSafe to drop >> communication midway through a file check-in. >> >> That's just un-f*#@king-believable. > > Why do you find that unbelievable? Is this the first time you have used > (or considered using) a Microsoft product? :-( > > To Microsoft's credit the above is also considered a flaw in CVS which > SVN has dealt with. SVN intends to be a better CVS than CVS, not just a > different solution for the sake of being different (and incompatible). A design fault in CVS is hardly "to Microsoft's credit" ! It's also worth noting that the worst you can do to a cvs server by using flaky network connections is mess up your current check-in. If your connection dies while checking in a bunch of files, some might be checked in, some not, and perhaps one in the middle will be stuck half-way. But all your old files in the repository are fine, so you can patch things up again. In the VSS case, a messed up write can leave your *entire* database in tatters, if it happened to be in the process of updating the indexes. Of course, SVN gives you either all or nothing for a checkin, which is much better. Far and away the world's toughest application of source code control is the sourceforge site. There are no doubt other sites with larger repositories, but no where else are there as many projects and as many users, ranging from the total newbies to wizards looking to use every feature of the system, and with network connections of all qualities over the world. They ran CVS for years, and are now switched over to SVN.
From: Pete Fenelon on 9 Nov 2006 02:53 David Kelly <n4hhe(a)yahoo.com> wrote: > To Microsoft's credit the above is also considered a flaw in CVS which > SVN has dealt with. SVN intends to be a better CVS than CVS, not just a > different solution for the sake of being different (and incompatible). True. It was very easy to migrate "culturally" into SVN because on a superficial level it behaves very much like CVS - once you're in there you can really start to take advantage of the new features. pete -- pete(a)fenelon.com "he just stuck to buying beer and pointing at other stuff"
From: David Brown on 9 Nov 2006 03:09 David Kelly wrote: > Grant Edwards wrote: >> >> There's a huge, basic flaw in VSS's design. It's a single, >> monolythic, database file with no centralized server or >> control. All of the clients bang away individually at the >> database file. If one client glitches the whole thing crumples >> to the ground like a house of cards. > > To which I wish to add that some here have advocated the same > client-fileserver approach when using SVN/CVS. I recommend one set up a > proper server so that only one application is modifying the archive > rather than a multitude of possibly different clients. > > When running client-fileserver every user has to have permissions to > modify every file in the archive. When running client-server only the > server daemon has to have complete access to the archive and the users > have to access thru the daemon. > > For me the 95% solution has been to host CVS on FreeBSD via ssh. > TortoiseCVS for Windows clients. MacOS comes with CVS preinstalled. > BBEdit does CVS (and now SVN) also. SVN would be a 99.9% solution but > I'd have to start doing things a bit differently. I wouldn't recommend > anyone start anew with CVS. It's worth noting that while any server software is going to run more safely (and probably faster) on a *nix system, Subversion has been specifically designed to run well on windows as well, just like Apache2 (as distinct from cvsserver and Apache 1.x, for which windows is very much a second-tier server OS). So if you are the only one using the source code system, use Subversion directly on your own file system. If there are several people using it, run it as a server (either svnserver for simplicity, or Apache 2 for flexibility). Run the server on *nix if you can, or windows if you can't.
From: Johan Josefsson on 9 Nov 2006 06:59
There is one annoying thing with SVN. There is AFAIK no way to tell that your version of a file is the same as the version that is labelled. In ClearCase or CVS, I can immediately see that my file (i.e. version) has a label (tag) attached to it. In SVN, I cannot do that. At least not from the command line. Am I right or have I missed something? Does anybody know? |