Slashdot Mirror

Hmmm, I've been using WinCVS on Windows for over 5 years now without any problems.
http://www.wincvs.org/

I do cross-platform development and use Windows, Mac and Linux systems almost every day. I've always been a Windows person but I was perfectly willing to let myself be swayed by my new Mac. From the first time I touched it, it was nothing but problems. The damn mouse accelleration feature could not be configured or turned off so I couldn't even navigate the interface. I eventually found a MS mouse driver that seemed to fix it but OS/X must have not liked it because it's gone now. The system would lock up nearly every day requiring a reboot. I figured out that I just had to not let it go to sleep or something. The rest of the problems I have had are probably due to inexperience with the OS and my inexperience is primarily due to the amount of aggravation I have had with my Mac. I only use it when I have to. Every time I touch it, there's a new irritation I have to deal with.

Yeah, OS/X looks pretty. Nicer than Windows. But, I prefer substance over style. Seems to me that being a Mac user now-a-days is more about being cool and hating Microsoft than it is about productivity. I don't need Apple to be cool. Being cool or not cool is not about what products you buy or what you wear. That's all a bunch of poser crap. There's little that irritates me more than Mac people thinking that they are somehow better then Windows people. It's so absurd as to be laughable yet I see it all the time. "When people see you have a Mac, they know you're a serious artist." I actually read that in a Mac magazine. It's BS. There's a very good reason why more artistic people use Macs than PC's. It's because Macs had the good desktop publishing, graphics and audio editing software before Windows did and so they gained a foothold with desktop publishing, graphics and audio editing people. You can do all that stuff on Windows now but the legacy of Macs still prevails among these users. I have no problem with that. I'm just sick to death of all the anti-Windows talk which is mostly based on completely invalid premises.

If people want to hate Microsoft, that's fine. Disrespecting people based on what OS they use just to make you feel better about yourself (not referring to original poster) is asinine.

Look at CVS integration for example. It comes "free" with Eclipse, and is way better than what JBuilder offers.

i've personally tried a round of window cvs software include WinCvs and TurtoiseCVS and I've gotta say both were incomparable to Eclipse. I don't know why there hasn't been a easier CVS software, or maybe it's because I'm not looking hard enough. That said, even if I'm building software on Visual Studio or another IDE, I would still use Eclipse to refresh the directory and synchronize with the repository.

If anyone knows of any better free CVS software out there, I'm all ears!

CVS (Concurrent Versioning System) is definitely the way to go.

Here are some links to get you started:

CVS On Windows

WinCVS GUI (very nice, uses Python undeneath)

Tortoise CVS

CVS NT Wiki

Component CVS for Windows

All of these are CVS for Windows tools. CVS is a great revision control system.

Due to the fact that SVN isn't available for Windows (a native port, no cygwyn stuff), I recommend either Perforce or CVSNT + WinCVS. I've used CVSNT at work and home for some time and it works great.

The market is currently quite rough, especially to break into. After being laid off when a product tanked on the market, I've gone a few months without having a single resume responded to - and I have almost a decade of professional programming experience that was applicable to the jobs I've applied for (and my resume used to keep the phones ringing daily for months when I posted it - the market has changed a bit).

I've been spending the extra time continuing development on my personal code library and projects, writing open source code, and working on a few products that I expect there to be a market for when they're done. That's how I'd suggest breaking into the field as well.

You have a very special situation though - you know, or can find out if you think about it and ask your colleagues, exactly what one fairly wealthy niche market needs. What software would help you - as a doctor - work more efficiently? What software have you and your colleagues found lacking? There's your first project :)

It won't be easy, and you won't make money fast. My recommendation would be to start learning about computers and computer programming now while thinking about products. As soon as you feel like you can design a useful program and have one in mind - take a shot at it.

Use CVS ( or for Windows, WinCVS ) or some other revision control so you can keep track of all the code you write (I wish I had when I started!). Estimate for yourself how long tasks should take - track those estimates, and figure out why they were right or wrong. Document everything, especially the code.

Once you have a product you think is worthy for your target audience - use it yourself in your work. Then let some colleagues try it out. Fix anything you find wrong with it, and ask your colleagues for suggestions.

Then, set up a website, advertise it, and try to sell it - or set up a project on SourceForge and make it open source - whichever you feel more comfortable with. On SourceForge, you'll be able to enlist the help of other more experienced programmers and together tailor the product towards excellence. If you sell it and it's successful, you'll be able to afford to switch careers to full-time programmer/entreprenuer and just work on your business.

That brings me to another point - if you aren't currently running your own doctor's office, start learning business skills too. They're just as hard to pick up as programming skills - possibly harder for some. Figure out what you'll need to do to start running your own software company. Even if you decide to write your own software as open source and become an employee for someone else professionally, this will help you at the negotiating table.

What I would NOT recommend is dropping out of medicine, getting a BS in computer science, and expect doors to be immediately open when you g

You can also set a flag (-kb I think) so that you can version control non-text files, and if you are using a GUI like WinCVS a great front-end to CVS, then it will usually automatically handle that for you.

I assume CVSGui doesn't work for you?

Microsoft uses CVS to develop Windows? I always knew there was something fishy going on!

On a more serious note... for future reference: If you have something like CDs with source code that you know you are NOT supposed to have, just shut up and don't go telling the whole world about it. Otherwise you could get into all kinds of trouble.

Have you tried wincvs?

http://www.wincvs.org

Ok,

1. Install Cygwin. Yeah it's a dumb shitty-ass pathetic installer, and those who built it should be slain and their bodies fed to pigs, but hey, the tools are nice when you are done.

2. Install CVSNT. Easy install, take it all.

3. Do yourself a favor. Add those two to the path. Right click on My Computer, select Properties, click the Advanced Tab, and click on Envionment Variables. Under System Variables, find the PATH statement, and add in the following :
;c:\cygwin\bin;c:\Program Files\CVS for NT

4. While you are in there, add a new System Variable: CVS_RSH and set it to SSH.

Now, it's all set up and ready to use, as long as you know how to use CVS. (an entirely different question).

Now, if you like GUI tools at all I highly recommend the following :

TortoiseCVS -- This can EASILY be setup to use SSH. As a matter of fact, the builds past 0.49 have it all ready to go. Read the docs, and you'll see.

and WinCVS -- Which is the king daddy of CVS Gui Apps for Windows. A bit clunky for my needs.

and Jalindi Igloo -- A SCC API plugin for CVS. What's that? -- It's allows Windows Development tools to use CVS instead of Visual Source Safe (VSS=a plague!). Sweet, simple and kinda nice if you like that kinda thing.

--
Wuff

Yeah, this reminds of of my office. We were using CVS as a repository and WinCVS as a client and it was working great. We the repository had no problems, it was fast, it was easy to use, it was easy to automate builds on multiple platforms, easy to backup, and generally just great. The only problem managment had with it was that you had to do something explicit to lock files (I hate file locking anyways. It is the pain of all projects that use it). So I coded up some tcl scripts to replace the functions in WinCVS so that no matter what, if the file was modifiable, it was locked (this part has less to do with open source as it does with having a scriptable UI). They were wishy washy for some reason. Instead, they bought a bunch of SourceSafe licenses. With the 8 thousand they spent on that, they could have hired someone, possibly even someone on the project, to put in a change to WinCVS to require locking. Instead, now we have 10 lincenses, and when we grow, we'll have to pay more and more. Why? It makes no sense.

Actually, my point is, that until someone makes their version control system a drop-in replacement for CVS, CVS will still remain the king.

I like the fact that I can use several different clients for CVS.

On Windows :

WinCVS is a nice CVS system for windows.

CvsIn is a plug-in for MS Visual C++ written by Jerzy Kaczorowski.

TortoiseCVS is a plug-in for Windows Explorer written by Francis Irving.

cvsscc is an SCC interface for CVS.

Jalindi-Igloo is a SCC interface for cvs using the WinCvs shared libraries. It's written by Graham Robertson and it's free!

There's also the command line version.

On Linux, there is a ton more choices.

The simple fact of the matter is there is a million different ways I can access the same repository, no matter my platform.

Until someone comes out with the server that supports CVS's whacked out protocol on port 2401, I ain't ever gonna switch.

I've been running the same CVS repository for about 4 1/2 years on an old Pentium 90 in my basement. I've got hundreds of project sitting on it, and it works fine.

Yes, I'll acknowlege that CVS has it's down sides, but hey, at least it's universal. ;)

Tortoise is a wonderful Windows Explorer plugin that gives you access to CVS fucntionality from regular old Explorer windows.

I don't use WinCVS (except as a library) anymore, because Tortoise is so much easier!

• CVSWeb
• Bonsai
• LXR
• TortoiseCVS

I haven't used this myself but surfing over to the WinCVS website, I found cvsscc. It's a project to map the scc stuff that MS uses to cvs. Another attempt, perhaps more mature, is Jalindi Igloo. The first paragraph from the website says:

"Jalindi Igloo is a program that allows you to connect Microsoft Visual Studio and other IDEs directly to a CVS repository. The program is completely free and can be used anyway you like."

These look to be just what you are looking for.

http://www.wincvs.org/TortoiseCVS/index.shtml

When I was (along with some other people, but mostly me) running CVS development, our most popular download was the Windows client (command line at the time, although WinCVS later got popular). Yet very little of the mailing list traffic, submitted patches, and the like were for Windows. I suppose one could point to reasons like whether people had the right compilers for Windows (cygwin wasn't as mature then as it is now, so we had both cygwin and Visual C++ ports). But I still would vote for the cultural explanation. The model of Windows freeware or shareware is basically a gift from the author to the user, whereas Unix free software is more often seen as a (potential) collaboration in which the users contribute.

I guess this won't go down well, but we use Mickeysoft's SourceSafe for all our version control and I would recommend checking it out. Admittedly there's the cost factor involved in that, and the administration. However, having used CVS for a while, there are limitations in that software that were hard to work around, and administration was no breeze either. No doubt it's improved in the past two and a half years, but I can't comment.

By far the best system I've used is Clearcase, but that requires an enormous effort in administration (we had 3 full-time and 2 part-time admins on it for a project spanning multiple continents and with some 80 developers, and that was just in one of the offices - I have no idea about the others). That was back before it was sold to Rational and running on HPUX though, and I've heard terrible stories about the performance of the Windows client. Oh, and it costs an absolute bomb.

My experience has been that a 30 minute course for the non-technical will bring them sufficiently up to speed on SourceSafe. A well structured SourceSafe database and a couple of clicks can allow non-technical people access and control over their documents at a centralised network location whilst maintaining version control. Note that the structure of the folders (Projects in SS terminology) is worth investing time in figuring out because it can make a world of difference to how accessible your documents will be - and that's a large part of the problem when you're dealing with non-technical people.

This of course presumes that you want a system that handles both code and document control. There are dedicated document revision control systems out there, but I have not had experience of them. At one point we built our own simple one, but I was never fully convinced of the benefit of doing that, though it leads me to believe that good commercial products may not be as plentiful as hoped for.

For the cheapest route, CVS is probably best. There are other GUI solutions available than PCVS, though I haven't tried them out, and I don't know how well they're supported. I presume you've found this page already. A quick perusal and TortoiseCVS seems a fair approximation to what you want (I presume your users are technical enough to use Windows Explorer if they are writing Powerpoint presentations), though their website is down at the moment (perhaps that's a bad sign).

I hope that's of some use to you.

Cheers,

Nixta

There are two separate issues in your question.

1. How to put MS Office and other non-text documents under version control

   I ran into the same problem a few years ago for documents produced by various word processors. I was the tech lead (translate: responsability without the pay) of a small team. We had documents coming from a variety of sources, and we were using RCS, which is the underlying mechanism for CVS, rather than CVS per se.

   When we had a "foreign" document landing in our e-mail, our solution for keeping track of it was to imbed an RCS identification string ("$Id$") in that document. Some document format supported comment (invisible) fields, which was nice. Otherwise, we had to use some "invisible" string, such as a 1-pt header on a page. That worked for RTF documents as well as some weird formats such as Quark XPress, and even a PostScript file from the guy doing the cover of the manual on a Mac. That's because these formats are basically text.

   Thing are more complicated when you get binary formats such as some MS Office native format docs. Assume you cannot reject the doc and require an RTF version (that is covered by the previous case). Then you need to set up a script that converts the binary document into Base64, slaps an $Id$ field in it and check it into your repository. Conversely, a check out requires you to remove the Id line and convert the Base64-encoded text file back into binary. I'd gladly cut-and-paste the 10-line Ksh code, but our lawyers want us to go through our "open-sourcing software committee" first. :-) You can automate the process within the CVS server.

2. How to have non-geek use CVS from their DOS/Win machine

   I had to teach my team to use RCS. Since then, cool GUI programs appeared, such as WinCVS (Check http://sourceforge.net/projects/cvsgui/. The site www.wincvs.org wasn't responding when I wrote this.) This is a GUI program that allows even an accountant to use a CVS server with a minimum of hand-holding. Give it a try.

Good luck.

- - SysKoll

Check out TortoiseCVS from the CVSHome website. It's an add-on to Windows Explorer that adds status dependent color shading to CVS controled directories and context sensitive commands to the Explorer file menu. Comes with a bundled SSH client for secure tunneling.

Easy to install and VERY easy to use, and no, I don't have anything to do with the project. I just use it.

Actually I find WinCVS *OK* but it's UI is horrid. I usually end up using the command line it's so bad. For most day to day things that I do in CVS I find Tortoise CVS to be far better. It integrates well with Windows Explorer and you can perform most CVS tasks by just selecting things in explorer and right clicking. It's pretty spiffy and it's actually based on the WinCVS code base.

I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).

Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML). If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.

In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:

1. Use a UNIX server, for both repository and pserver (client/server, runs on port 2401 by default, setup in /etc/inetd.conf) daemon (recommend both be on the same system, although there are exceptions to this rule). The UNIX CVS server is just so much more flexible, although our SV office uses CVS on NT (but they are NT-only on the client side). Since most Linux distros come with the latest CVS software, stick with Linux for your server (the CVS server/repository should always have the same or later version than any client).
2. If performance is important, make sure your server has a lot of memory if you run pserver (again, client/server daemon on server's port 2401). When you do, the server needs 1.2-1.5x the memory of the largest file checked in, otherwise, thrasing will occur as you swap pages to/from memory. Again, I _highly_recommend_ you run pserver for access from NT clients.
3. On the UNIX side of things, you don't have to use pserver. You can directly access the repository via NFS mounts. This is slower, but, for large files, you do not run into the thrasing issue on the server. In a nutshell, pserver puts all the burden (incl. memory usage) of the diff/commit on the server, whereas clients that access the repository directly do all the work. Even though you run pserver (for your NT clients), you can still access the repository directly on UNIX clients.
4. Do *NOT* checkout via NT to the same directory as via UNIX. E.g., if /home = \\server\home, do not try to checkout to /home via UNIX and then commit via NT from \\server\home, or vice-versa. The reason for this is that while the repository is OS-independent, the checked out working directories have OS-specific details (e.g., drive letters when checked out via NT, which the UNIX cvs client won't understand -- plus LF/CR issues where NT gets the later automatically added). Either adopt one of two philosophies (or both, depending on your user):
   • If you need to have working files accessable in the same place from both NT and UNIX (e.g., /home and \\server\home), then do all your cvs actions from the _UNIX_ side. The only issue you'll run into is any LF/CR that a Windows application would expect (since only LF will be used for line breaks since the working directory created/modified by UNIX). Since most of my Windows development tools don't mind LF-only breaks, I didn't have any problems with this.
   • The other philosophy involves a strict separation of working directories from NT and UNIX. Note, both clients still access the same, central repository and the same info. But when working, check out files via NT to a NT-only area and files via UNIX to a UNIX (possibly NT-also) area. This is what we also do with some people: Check out via NT to their local hard drive (which cuts down on network usage when they work), committing at the end of the day (for backup purposes), with other files being checked out to UNIX on the file server (and then accessable via both UNIX and, limited, NT over NFS/SMB shares -- which doesn't need to be committed at the end of the day since it gets backed up on the file server itself).
   • The use of each will depend on your workflow, possibly a per-user thing.
5. Be cautious about what you modify the CVS respository directly, but don't be shy to do it occassionally when you absolutely need to. This is what I love about CVS over other VC systems, a very understandable repository setup. Don't do it unless you cannot get a cvs client command to do what you want, don't do it reguarly and manually log anything you do to the repository for future reference. After a year and a half at my job, I have probably gone into the repository about 2-3 dozen times and haven't had any issues yet. Again, I haven't had such good luck with commercial systems and direct repository modification (when required).
6. Even if you are using a UNIX-only checkout environment, you can always use the nice, visual WinCVS client on the Windows side (provided you have a Samba share) to look at working file status (e.g., modified, current, etc...), but don't use to checkin/out UNIX working directories. If you are checking out via NT, then WinCVS will be a natural client choice. Just configure it for pserver, port 2401 and you'll be cooking.
   [ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
7. Don't forget to set some basic variables in all your user scripts (or in a global script called at login), e.g.:
   • CVSUMASK 007 -- just like a regular umask, only for cvs checkouts
   • CVSREAD 1 -- set if you want to force users to do a "cvs edit" before editing a file (great for keeping track of concurrent edits/development), unset (or don't set) if you don't.
   • CVS_SERVER server and CVS_PASSFILE $HOME/private/.cvspass -- if you use pserver (client/server) access (or unset/don't set if you don't).
   • CVSROOT /home/cmroot/cvsroot or CVSROOT :pserver:$USER@server:/home/cmroot/cvsroot -- the former for direct repository access by client, the later to use pserver.
8. Also get some basic aliases down for your UNIX clients, e.g.:
   • alias cvs '/usr/local/bin/cvs -d /home/cmroot/cvsroot' -- accesses CVS repository /home/cdroot/cvsroot directory
   • alias cvs '/usr/local/bin/cvs -d :pserver:$USER@server:/home/cmroot/cvsroot' -- accesses CVS respository on SERVER at /home/cmroot/cvsroot via pserver (client/server)
   • alias noncvs "cvs -n -q update -I '! CVS' -r HEAD" -- List all non-current or unknown files in working directory from repository (I use this all the time)
   • alias noncvsi "cvs -n -q update -r HEAD -- same as previous, except apply ignored file list (which are listed in file $CVSROOT/CVSROOT/cvsignore -- which you'll want to checkout and modify for your site).
9. Do *NOT* make your server public. CVS is NOT a secure server, unless you use something like Kerberos client/server (instead of pserver, on a different port, I've never done this), or pserver with SSH as the remove shell. If you are going to run a publicly accessable CVS server, you'll want to run in at least pserver mode using SSH or, in the worst case, pserver with different usernames/passwords directly in the CVS admin files (rather than using the default of the local UNIX accounts). I highly recommend _against_ running a server that is both internally and externally accessable. If you need to, setup two separate servers, with two separate CVS repositories and run a cronjob to update the external server on a regular basis. Better yet, get familiar with "cvs export" on automating the export of files from the CVS repository (withOUT working CVS info) to archives, external servers, etc...
10. Lastly, if you have not adopted Cygnus' Cygwin GNU environment as standard on your NT desktops, do it now. No need to pay others for UNIX tools on NT, Cygwin is all you need. Do it even if you don't use GCC, and do all your development via Visual Studio, etc... There are just too many good UNIX CLI tools to ignore in there and you'll wish you'd had them. A CVS client is included (or you can use WinCVS').

[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC). VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1, :2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]

-- Bryan "TheBS" Smith

If you're using strictly MS tools and you're not dealing with a lot of files, then VSS should do OK for you. Visual C, VB and family make it very easy to check files in and out of VSS, and it also makes it easy to deploy content to IIS based web sites. (although I know nothing about how secure that is)

If you're dealing with a large project, I think that it greatly increases the chance of the VSS database corrupting, which to me is one of the biggest flaws and a major reason why I would not use VSS.

The advantages of CVS are:

Simple file format eliminates chances of corruption. I've moved our repository to 3 different machines without any problems...I just had to tarball the cvs root directory and move it.

Support for multiple OS's, including a VSS-like client for windows

Comes by default with many Linux distributions, so all you have to do is dig up that old 486, put a good size HD on it, and you have instant version control.

Conflict resolution works just as well as VSS, if not better.

No license fees. :)

Some other gooey CVS frontends:
wincvs (windows)
maccvs (mac)
pharmacy (gnome/UNIX)