ACPI administration advocacy advocacy advocacy opinion alsa amarok apache apple apt aptitude audio audo authentication automount avi awk bash BIOS boot business cache calendar calibre cdr cdrecord censorship commandline computerscience console convert cron cut database date debian degree design desktop development disk dpkg dvd economics education emacs email europe exim faad ffmpeg file files firefox firewall flash foss freedom ftp fun fuse git gnumeric graphics grep growisofs grub gtkpod hardware hardware html idiocy image imagemagick images installation ip iphone ipod iptables iso itunes ivman kde kernel keyboard knoppix lame laptop latex linux locale lockin longlines m4a microsoft mimetypes minitab mount mp3 mp4 mplayer multimedia music mysql network nfs nfs4 nmap openbox openoffice opinion opinion partition pdf perl php politics postgresql printing privacy programming rant remote rhythmbox rss rsync rxvt scp screengrab screenshot script scripting scsi security sed server shell siteadmin sitenews sitesoftware skype skype slackware sound sox spam spreadsheet ssh statistics subversion sudo svk swap t23 t43 terminal text thinkpad thunderbird time timezone ubuntu udev upgrade usb usbmount users uuid versioncontrol vfat video vnc windows wine wordpress wordprocessing X40 xwindows xwindows youtube
I'm still exploring svk. Sometimes the documentation is a little incomplete. Sometimes I get completely confused.
The way svk works is that you sync an external repository into a local one or 'depot' in svk-speak. When you checkout something to be your working copy (something you actually amend), then you are checking it out from the depot and not from the svn server that is holding the external repository. Right?
Then I understood from the documentation that if I committed a change in the working copy, by doing svk commit, then the changes would be uploaded to the depot, but not to the external repository. So, I was a bit dumb-struck when my changes were not only uploading to the depot, but then to the external repository as well. What I hadn't realised was that this happens when the depot is a 'mirror' of the external repository.
So, in svk how do you know what mirrors you have, what depots and so on. The answer is in the magic word list.
The word 'list' does many things in svk.
With no arguments, this lists all the files in the current directory that are in the depot. With the -v or --verbose switch it also gives its revision numbers, the author who committed the latest revision, plus other stuff. Pretty much the same as normal svn
This lists how the paths in the depot, 'depotpath' in svk-speak, maps to the file system. It might give something like this:
Depot Path ============================================================ // /filesystem/path/to/depot
This lists all your checkout paths:
Depot Path Path ======================================================================== //path/in/depot /home/working/copy
This lists all the depots that are mirrors of other repositories, so that when you commit to them, the changes will be uploaded to the mirror. The output is something like this:
Path Source ============================================================ //path/in/depot https://url.to/remote/server
This lists all the patches that have been applied (and that svk knows about).
Once I discovered all this, I discovered it's easy to do other things, like copy files from one depot to another, or to easily switch a depot from one directory or partition to another. Or to have a number of different depots on different computers.This makes for powerful and flexible development.