|
dumb CVS question: SOS
We're about to start using CVS (other source controls are not an option). The repository and checkout directory is on a Unix box. IDE - is on Win32. IDE knows how to open and save files remotely from Unix checkout directory (you shouldn't drag them on Windows).
We don't like the idea of command line CVS interface. Here is the question: is there any client for CVS which would checkin from and checkout to the same box CVS is installed on? But would have some more friendly UI?
Most clients we've found would bring actual file to Win32 box, and then send it back - not an option. We want client just to give CVS a command to check in out. Web client would do as well.
anon
Tuesday, February 3, 2004
"Most clients we've found would bring actual file to Win32 box, and then send it back"
Just a question, what do you think check out does?
Simon Lucy
Tuesday, February 3, 2004
Simon,
thanks for replying, we have sandbox on Unix, we want CVS to use UNIX sandbox for checkins-checkouts, but we want it to be managed not via command line, but some sort of remote GUI or Web Interface. No, we do not use X-Windows or anything alike.
So we want something which we could install on Unix box (Web based) or Win32 (GUI), which would actually only tell CVS server what to do, not transfer files back and forth.
Have you, by any accedent, heard of such solution?
anon
Tuesday, February 3, 2004
As far as I know, CVS is a pull methodology, not a push. In other words, you need a client on your sandbox pulling the files to the sandbox - the CVS server doesn't push files to a location.
So you're going to need a CVS client on the Unix box and you'll have to build a web interface that will run it.
For what it's worth, you appear to be losing 99% of the reason you want to use CVS - if everyone is working on the same files in the same location, you don't have concurrency control. With all due respect, this sounds pretty silly and artificial to me. :-)
Philo
Philo
Tuesday, February 3, 2004
Ok, checking out a file (if it doesn't already exist), means that its extracted from the source control and copied to the current directory tree.
You don't edit in place within CVS, the sources move in and out. Yes, as files are changed only the differences are checked back in and differences checked out and merged into the local copy.
But the files move and you have to have all of the files in a tree for it to make sense.
If you don't want the files to move across the wire then you'll need to check them out on the Unix box in that user's home directory tree (don't check them out to anywhere public they'll get overwritten by subsequent check outs). To do that in a graphical way I'd suggest using an X Windows client and then something like CVSGui or LinCVS.
I guess you could share the directory using SAMBA but then the traffic will come across the wire and then back again, which is 1) pointless and 2) not what you seem to want to do.
Simon Lucy
Tuesday, February 3, 2004
If you don't have X-Windows and you don't want to use the command line or shell, how do you edit the sources on the Unix box?
If you use any kind of editor that can open and save using FTP you're still copying the files across the wire, and its likely to be less secure than using CVS across ssh.
Sometimes the universe doesn't want to be the shape you want it to be and you have to learn new ways to navigate.
Simon Lucy
Tuesday, February 3, 2004
Philo,
thanks, good point.
As to concurrency control - we don't really need it at the moment, we'll do it later by dividing sandbox and creating one for each in home directories - its stage II of painless source control introduction. Ideally we would like some checkout-and-lock-it type of source control, but we have to use CVS.
That's exectly what I was thinking, we'll probably have to built Web Interface to command line Unix client ourselves, which is a bit of overhead and then try to build simple web interface to it. Just I though, may be someone out there already has done it.
Thanks again for "pull" not "push" clue, it helps.
anon
Tuesday, February 3, 2004
Simon,
we have a web project, source has to be on a web server, so we could run and debug it. Web server and application server on Unix. CVS as well.
You're right, our IDE pulls files accross the wire using actually some kind of HTTP like protocol and then uploads them back, after that they got compiled on the server, before they can be run, tricky, isn't it? :-)
I did though about SAMBA, but out religious Unix guy said its not the way to go, something uncertain about letters case and permissions. He couldn't say exactly what is it, but was "absolutely 100% sure", that he saw somethere its really dead end. It's hard to argue with him, as he has very loud voice and I still hear noice in my ears...
anon
Tuesday, February 3, 2004
"Ideally we would like some checkout-and-lock-it type of source control"
Actually, no you don't. Those solutions simply do not scale.
Reading your next reply showed me the problem - you're doing it wrong. :-)
What you want to do is think of CVS as holding your source code, and that's where you get it when you need it, whether for development, testing, or deployment.
So - developers check code out of CVS to work on it, then check it in when they're done. When it's time for QA to go through a site, they check the code out of CVS, comfortable that they have the latest code.
"But how do we run a website with code in CVS?" you ask.
You check the code out of CVS to your web directory.
"But that's a pain in the ass" you say
Let me introduce you to Ant/Nant and continuous integration - there are services you can run that will watch CVS and, when the source code has changed, will pull the code, compile, and put it in your website. Automagically.
With intelligent branching and tagging, you can have the same source tree for development, test, and production.
Bottom line - you *really* need to learn to use this tool if you want to save yourself a lot of heartache and a lot of manhours. It's the swiss army knife of configuration management.
Hope this helps,
Philo
Philo
Tuesday, February 3, 2004
FYI, at my last job I was developing for (compiling and running on) Linux and wanted to edit using a Windows editor: so I used CVS and gcc on the Linux box by telnetting to Linux from my Windows workstation, and editted in Windows by having my Linux directory shared via SAMBA.
Christopher Wells
Tuesday, February 3, 2004
We have been fairly successful using CVS as:
1. Open up a terminal (via ssh or telnet).
2. Login as your Unix account.
3. Checkout via command line.
4. Mount our samba share.
5. Use IDE of choice on the client computer.
Regarding your unix admin. Make it clear in a public way that your requirements for source control are x, y and z and that most of the free world does it this way. Challenge your unix admin to come up with a solution to meet these needs or implement what you have suggested. If the unix admin does not meet your needs, get an old system laying around and install a free OS (i.e. FreeBSD or Linux) and implement your own repository (with backups).
Don't waste time building a web interface or anything that needs any more maintenance than the repository, just spend the time to learn how to use the tools and focus on the software that makes you money.
Good luck!
m
Tuesday, February 3, 2004
I guess the IDE is using WebDAV. In that case will the IDE also support macros that will run your checkout/checkin?
Simon Lucy
Tuesday, February 3, 2004
Simon,
yep, IDE can support custom code on Open-Save-New-Close (before and after) events. But I don't want to go there yet.
While doing research I've found interesting article by Philip Greenspoon (ArsDigita, remember?) which he wrote some years ago: http://philip.greenspun.com/wtr/cvs.html but still very true in our Web Development situation. I recommend it to everyone, who has the same trouble.
Philo, thanks again, I'll take a look on automated services you've mentioned, it might be it for us.
anon
Tuesday, February 3, 2004
Philo,
"scale" ? :-) People here usually get downsized, not hired, I think "checkout-and-lock" does scale down well ;-).
anon
Tuesday, February 3, 2004
Philo,
could you please drop some links on ANT/NANT, can't find it myself. TIA.
anon
Tuesday, February 3, 2004
> painless source control introduction
Painless? Are you sure?
Tuesday, February 3, 2004
I'm somewhat confused by the question. The whole point of a source code control system is to let files co-exist on multiple machines aside from the server, and then once changes have been verified as correct, the code is then checked in/committed back onto the server as the latest version, (integrating with other changes automatically where possible).
If you're new to CVS, I highly recommend this: http://www.pragmaticprogrammer.com/starter_kit/vc/index.html. I bought the PDF version as I'm outside the US, and am very happy with it. I'd suggest you still need to get a basic understanding of what the common command line options are in order to use CVS effectively.
If you're developing on windows I recommend http://www.tortoisecvs.org, there's also another GUI client http://www.wincvs.org.
If you're feeling brave it would be worth checking out subversion as it addresses some of the annoyances of CVS (that is, it handles file renames, and atomic commits).
There are links to subversion at the bottom of the tortoisecvs page.
Gordon Hartley
Tuesday, February 3, 2004
I agree with Philio, (n)ant rocks, particularly when combined with nunit / (x)unit.
I just wish I got the opportunity to use it more often :-(
http://ant.apache.org/
http://nant.sourceforge.net
http://www.nunit.org/
Should get you started.
Gordon Hartley
Tuesday, February 3, 2004
Gordon,
many thanks. In our case source control is more nessesary for keeping historical track of changes, than anything else. We have fairly large web application and only three developers non of which is usually changing same part of the system. What we need to enforce changes description mechanism (when you're booking file in you have to put comments on what you've done) and create historical audit of the code.
For us its also would be a versions control tool, but very little to do with concurrency conflicts resolution.
anon
Tuesday, February 3, 2004
anon,
Erk. Sounds like square peg in a round hole / wrong tool for the job if you ask me.... Is this a cost issue, or political or something?
I don't know of anything that will give you what your after - you may have to roll some shell/perl/python/ruby scripts
that would trigger on (or even take control of) a commit and verify then accept, or reject on whatever you deem as the minimum requirements, and roll the commit back out if required. The fact that cvs is not atomic may well do your head in though getting this to work flawlessly - you might be better off just volunteering to commit the code yourself....?
I don't think there's a reasonable solution for what you're after.
Gordon Hartley
Tuesday, February 3, 2004
Gordon,
I think that source control suits our goals well (CVS because its already being used on QA stage and as they say "based on price/quality ratio free beer bits any competition").
In future we may use it to resolve concurrency as well. Who knows...
anon
Tuesday, February 3, 2004
Sorry not "bits" - "beats"
anon
Tuesday, February 3, 2004
This smells of the 'we have to do it different syndrome' that seems to pervade our industry. Why take a quite standard process and bastardize it into an unmaintainable long-term nightmare? Sometimes (more often than not?) adapting your processes to the 'world normal' is the most cost/time effective solution.
Anon, compare the (short/long-term) costs of these two options:
1) adapting your process to the 'normal' usage of CVS (pserver, wincvs, tortoise, etc).
2) creating new processes/programs/interfaces on top of CVS to support your 'unique' needs.
Consider that #2 will take n x10 (or x100 hours over time) to build, maintain, and train. Wouldn't those hours be better spent on actual income production activities?
~dave
daglenn
Tuesday, February 3, 2004
Dave,
you're probably "the smart ass". So tell me then, should I replicate a web server, db, batch processes enviroment on each PC? Or should I checkin after each change just to test if it works even if I discard changes afterwards?
Give me critics, but understand the need first.
anon
Tuesday, February 3, 2004
Anon, while I'm a huge detractor of the "don't answer the question" type responses like Dave's, I happen to agree with him. You haven't said anything yet that indicates you're doing something unusual, so the first thing you really need to ask yourself is...
"Are we really the only shop doing web development with source control in place?"
Since I'm pretty sure the answer is "no" then you need to look around at other shops and *see how they do it.*
We understand you're in a comfortable mode, except when you look at your original post ("SOS"?) you're not that comfortable. So you may have to change the way you work to get things the way you need.
As far as everyone having their own webserver - I don't know about Unix shops, but that's the way I've generally seen it done in Windows shops.
Philo
Philo
Tuesday, February 3, 2004
Philo,
we're using some non-mainstream soft for web development and due to historical limitations we can't make use of virtual web servers either.
I've done a massive research on web today and this forum is just a part of it. My first thought was: "Many people out there are doing same or similar thing, I just have to find how". As many replies here show very little people have actual solutions to the problem. Mostly its just noise.
I've been given only one day for whole research and its likely to be the only chance to "get it right" in my organisation as we have loads of work.
Whole CVS issue emerged as a result of "live" error when suddenly appeared that we unable even to figure out what version of code is on "live" and what kind of changes led to the error.
No, its my second month on this job, so its not my fault. Previous guys cutted and pasted entire source directories to create new functionality, they would go on one of "live" boxes and fix things there and then forget to put same changes on dev or anywhere else. They were strongly opposed to any source control "as it will bring massive overhead to our cut&paste RAD methodology". Comments? You're laughing.. Concurrency issues? No control at all.
Its first step to bring development in order, if I ask for too much change of existent process they will never use it. QA guy is using CVS on test and realease boxes, but he has to checkin everything he can manually - and its not error proof at all.
I've never used CVS before myself, but no one will buy us any commercial system.
Only chance is create alias with QA guy and push this thru.
It's 10-th hour I'm at work today and reading replies like Dave's doesn't encourage me to be polite. Sorry for that.
anon
Tuesday, February 3, 2004
I thought there were already plenty of solutions given, so I don't feel bad for 'butting-in' ... but just in case here is what I've seen. I've managed and worked in various web shops for 7 years now. All definitely had source code control systems (cvs, pvsc, sourcesafe, rcs) and they have used various combinations of:
1) every developer has his own environment. This is the norm and usually the ideal. You get your own sandbox, under your control, and it's always available. Keep it as current as prudent depending on the integration state of your changes. This is usually combined with #2 or #4.
2) developer's share a common web development and/or test environment. This is good for releases and more thorough testing/qa/load-testing schemes.
3) developer's share a sandbox. This is only viable for a very short time and a limited number of developers (1-3 maybe).
4) a continuous build is running on a common web server pulling from the source-code system of the day. This works great in combination with #1 and can help ensure that the codebase is in a 'releasable state' at all times (it builds, it passes tests, and it can be verified to run correctly).
As a manager I would nearly always recommend that you spend your time on things that produce income rather than burn it, especially in the case of existing solutions that can be easily integrated. That and 23+ years in this business tells me that 'keeping the simple things simple' gives a higher probability of success.
~dave
daglenn
Tuesday, February 3, 2004
"Mostly just noise"
Well, forgive me if I'm wrong, but this is a pretty important, yet up-till-now-withheld piece of information:
"we're using some non-mainstream soft for web development and due to historical limitations we can't make use of virtual web servers either."
*Now* the reason that everyone has to work on a single server starts to make sense.
Philo
Philo
Tuesday, February 3, 2004
Philo,
yep, its a shame, but many things are just hard-coded. Everything I can do now is just sing "I wasn't me!".
anon
Tuesday, February 3, 2004
It wasn't me
anon
Tuesday, February 3, 2004
Anon
I'm sorry if my reply seemed too harsh but costs of 'custom' process solutions need to be considered very carefully. After all, when is the last time most IT shops were able to completely stop whatever process is currently in place. Be conscious/careful of the legacies you create.
I appreciate your struggle to bring a basic necessity to your dev. shop, it can be painful to overcome entrenched processes/attitudes. You will definitely need to make compromises, just don't compromise yourself into a new position (head source code control do-bee) that you don't want, which is likely what a custom solution will get you (among other things).
~dave
daglenn
Tuesday, February 3, 2004
Thanks Dave,
sorry for being rude. We will probably go for one shared sandbox (three developers) as it allows to keep one enviroment. We will probably readjust it for separate sandboxes after some time (we have to recode certain bits).
Actually we almost go for Greenspoon proposed solution (link above), everything except automated checkins, as we want people to put some comments when they checking code in.
anon
Tuesday, February 3, 2004
Sounds workable. I would vote for required comments as well. Though the temptation for 'n/a' or 'wip' is high it does force developers to think a bit before they commit.
I would also recommend running CVS as a pserver, setting up a Samba sandbox-access solution (it's really not that hard) and using Tortoise as your CVS client (generally quite painless).
~dave
daglenn
Tuesday, February 3, 2004
> question: is there any client for CVS which would checkin
> from and checkout to the same box CVS is installed on?
Take a look at the Zeus for Windows IDE:
http://www.zeusedit.com/lookmain.html
It uses the Win32 CVS command line client tool to provide an IDE interface that allows for seamless check out, check in, revert etc integration with CVS.
Jussi (www.zeusedit.com)
Tuesday, February 3, 2004
If, because of your pariticular circumstances, all your developers are forced to work in the same sandbox, I might suggest simply using RCS instead of CVS to prevent accidental overwriting.
Then, when you move to per-developer sandboxes, it's pretty easy to move a bunch of RCS files into CVS.
Bill Tomlinson
Wednesday, February 4, 2004
 Recent Topics
Fog Creek Home
| 
