ec2-18-204-55-168.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic
Concurrent Versions System
Very useful for code development.
Has anyone had much experience of [Win CVS] or [CVS NT]? I'm not having any luck setting up even basic repositories and I can't tell if it a lack of understanding of the software or of the basic concept of CVS which is hindering me.
MoonShadow? Any chance you could talk me through setting one up on my laptop when I'm in the area next weekend? Sometime when SunKitten is doodling or something so we don't bore the life out of her :) --Kazuhiko
- (PeterTaylor) What do you mean "setting up repositories"? Do you want to create a repository on your Windows machine, or checkout a repository you don't currently have from another machine?
- Either / Both... I think. Basically, we have no CVS type system at work and I want to implement one. Eventually, this will consist of a central server (Win2k server) and roughly four clients (Win2k desktop). Currently, I just want to get _something_ working so I can play around and understand how it is supposed to work. --Kazuhiko
- Sure ^-^ - MoonShadow
- Thanks :) --K
PeterTaylor is currently setting up the company's new toy^H^H^Hserver. Installing CVS, he is presented with this:
x CVS pserver is a client-to-server mechanism which can be used by CVS as a x
x replacement for the standard "server" method, which uses "rsh", or an rsh x
x compatible program, such as ssh. It is more efficient than the standard x
x server protocol, also supporting its own password files, making it more x
x secure. However, it may be a security risk, and used to contain a security x
x problem whereby a remote connection may have been able to read the passwd or x
x other security-related files on the system. x
x For this reason, it is recommended that you switch this option OFF, unless x
x you know that you want it specifically. CVS now only allows access to x
x particular repositories specified on the command line. x
x CVS pserver will be installed in inetd, using tcpd wrappers if you answer x
x "yes" to this question. x
x <Ok> Erm, how do I say "No"?
- Oh. The question is asked on the next screen. How, erm, not confusing?
- That's a fairly common (and IMO annoying) idiom in Debian - explanation with "OK" then question with "Yes/No".
- Debconf notes are deprecated, but that doesn't mean they don't get used. *sigh*
Anyone come across/experienced "Subversion"? It's another CVS type thing but, just at the moment, that's really all I know about it. --K
- MoonShadow had to do an evaluation report on it. If K-sama can hang on 'till he gets to work tomorrow, he'll post it. Basically, it's good in principle, better than CVS in some respects, but the current implementations are flaky in one or two places, which may or may not affect you. Finding a decent GUI for it is tricky, too - both the main ones have flaws (the explorer-a-like tortoiseSVN is quite frustrating to use for anything advanced, the [other] was unresponsive and unstable at the time of testing).
- PeterTaylor's been keeping an eye on it, and isn't of the opinion that it's stable enough to switch.
Excerpts from MoonShadow's Subversion report notes (written with a view to switching away from MKS Source Integrity; just to highlight one point - "checkins and updates are guaranteed to be atomic for operations involving more than one file"; this is the biggie! This is the reason to switch if your current system doesn't do that).
- performs well in daily tasks in areas where MKS SI slows to a crawl bringing the system down with it (tag/branch, check in, update, check for updates etc take around 10-20 seconds in everyday conditions (performing operation on entire project but only a few files changed); checking out ~600Mb project from scratch takes 20 minutes, compared with MKSSI's 50)
- checkins and updates are guaranteed to be atomic for operations involving more than one file (i.e. an end to problems where someone updates their working copy while someone else is checking stuff in)
- missing features:
- filters on files you're viewing (e.g. show only changed files) - although the "check for updates" context menu is a good enough replacement for the most common use of these
- file locking (this is deliberate - their view is that it's not generally helpful and can be actively harmful)
- fetching revision history (equivalent of MKS alt+enter) is slow (~10-20 seconds).
- no progress feedback even on slow operations
- some distinctly unhelpful error messages
- nasty syntax for branches
- merging across branches slightly hacky, involves knowledge of revision number when branch was created or when last merge was carried out
- Revisions are global, not per-file. Every time you commit something to the repository, you create a new revision of the repository.
- Working directories can contain a mixture of revisions of files and directories.
- Files / directories that come from different branches will be updated to the tip of their respective branch in an update.
- committing to repository
- Sets of files and directories committed in a single operation share a revision number. Partial commits are impossible - if committing any file fails, *nothing* is committed, and no-one sees the files you are committing until the entire operation succeeds.
- updating from repository
- Subversion will automatically merge from the repository on update and notify users of conflicts, much like MKS was able to. After the update all files from any branch will be at the same revision on that branch, even if someone committed files to that branch since you started updating.
- tags, branches
- Copying parts of the repository uses links and is cheap both in time and space.
- Revisions are implemented internally as cheap copies. The idea is for us to also use cheap copies as tags and branches. A tag or branch is simply a copy of a particular existing trunk or branch revision or a working directory containing a collection of files/directories that may come from a mixture of different revisions. The idea is that each project in the repository contains a trunk directory, a directory where branch directories are stored and a directory where tag directories are stored; the trunk directory and each tag and branch directory contains a cheap copy of the entire code tree. Copies also contain links to the file's past history, so logs work as you would expect. Subversion doesn't enforce any policies on the repository structure; it's up to us to specify policies and it's up to us how we interpret areas of the directory hierarchy.
Thanks for that MoonShadow. I think I need a bit more background in CVS to completely understand all that, but I also think I'm not going to get that background unless I just go ahead and start using one. Given that our requirements at this time are fairly simple I think I may as well go with Subversion for now.
Were you using any kind of GUI with that or just command line? --K
- [This] and [this] GUI. Both were flaky in different ways. There are a lot more GUIs to choose from these days, but I've not looked at any of the others. - MoonShadow
- TortoiseCVS? is nice - we use it at work. Presumably the 2nd link above is the equivalent for Subversion? --M-A
- Presumably so. My experience was that it was slow to display the overlay icons, and a lot of source control functionality I often use like "diff between revisions" and "show only local files which are different from repository tip" was either not present or buried *very* deeply in the menu system. This was a few months ago now, though - it might well have improved. - MoonShadow
- Ah - for that sort of functionality, we have [ViewCVS] (which also does Subversion, apparently). And Tortoise is being improved all the time. I find that the combination of the two does just about everything I need, with the command line as a fall-back for really obscure things I want to do (which happens quite rarely, TBH). --M-A
- Out of interest, my bosses are quite worried about the lack of locking functionality - how does that work out in practice? - MoonShadow
- Lack of locking? I think we have locking... at least, if someone else is accessing the same file (directory?) as you, it says "waiting for CVS lock on <filename>...", retries after a few seconds and repeats until it gets the lock. Unless you mean in Subversion, but I don't know anything about that. --M-A
- Ah, brain glitch - I was in "she uses Subversion-capable GUIs therefore she uses subversion" mode, even though you said you were using TortoiseCVS? ^^; sorry - MoonShadow
Probably a silly question, but: if you "update" to an older version of a file in CVS, how do you get it back to a usable state?
We're up to revision 1.116 of tokenise.c and I did
cvs update -r 1.114 tokenise.c
Later I wanted to commit a new version of the file. Understandably it won't let me commit it while I still have version 1.114 checked out, so I did
cvs update tokenise.c
(so that it considers me to have a modified version of 1.116, rather than of 1.114) and then tried to commit my new file. I got this message back:
cvs commit: sticky tag `HEAD' for file `index/compile/tokenise.c' is not a branch
So I did cvs status to make sure everything was OK and it looks like it was:
cvs [commit aborted]: correct above errors first!
File: tokenise.c Status: Locally Modified
So I even tried deleting tokenise.c (having backed it up elsewhere, outside of the whole source tree) and doing cvs update -C tokenise.c to update to the latest version and completely get rid of any other versions I had (or it thought I had). This worked, and I got the expected message:
Working revision: 1.116
Repository revision: 1.116 /proj/cvs/i2e/index/compile/tokenise.c,v
Sticky Tag: HEAD (revision: 1.116)
Sticky Date: (none)
Sticky Options: (none)
cvs update: warning: `tokenise.c' was lost
and I copied my backup version back in over the top (which should be the same as editing the fresh version in a text editor; CVS stores its metadata outside the actual file AIUI) and tried to commit it, and got the same message about HEAD not being a branch. Eventually, I checked out a whole new copy of the source tree, made my changes to its copy of tokenise.c (again, by copying my backed-up one in its place, rather than in an editor) and committed it, and that worked fine.
I've had to do this before - just give up on the original checkout because it's now corrupted in some way, and start working from the new one in future. But there must be a better way...? --Rachael
- cvs update -A tokenise.c --Admiral
- Thanks! --Rachael
CategoryComputing | CategoryAbbreviation