versiebeheer op bestanden met Subversion

1. versiebeheer op bestandenmetSubversion HG 5.91 28 september 2009 Reinier Post

2. is software voor versiebeheer op directory trees (mapstructuren?) met bestanden. http://subversion.tigris.org/ Subversion

3. Multiple versions of a file: for example a document you’re editing + a backup copy your document at home + a copy at work your version of a document + Harry’s version a copy of a webpage + the version you modified with your suggestions versiebeheer op bestanden

4. Multiple versions of directory trees full of files: a website a LaTeX document (single author or co-authored) the source code of a computer program a user software profile (config files, startup scripts, utilities) version control on whole directory trees

5. locate .oud; locate .old locate /home | grep -v '[~%v]$' | ~rp/bin/previsprefix most files are completelyredundant - not worth saving! local copies of available files copied from elsewhere files generated by programs from other files temporary backup copies different versions of the same file: only partially redundant => version control problem: what to save, when, and where? demo 0: find some examples

6. locate /home/rp | grep -v '[~%v]$' | fgrep -v rpsoft | previsprefix diff diff –u diff –r diff is a standard Unix tool (since the 70s) only useful on plain text files, including structured plaintext(source code, XML , etc.) if formatted uniformly demo 1: diff

7. diff –u a a.modified > a.diff rm a.modified patch < a.diff # turns a into a.modified ! patch is a standard Unix tool (since the late 80s) only applicable when you can work with diffs allows “merging” different changes into single result demo 2: patch

8. let user explicitly commit versions of a file remember all versions the user doesn’t remove be “clever”: save the diffs! every version has a number every version has an (optional) log message RCS can record info about the version in the file written in 1985, soon very popular RCS: version control on a file

9. locate /home/rp | grep RCS # on win.tue.nl Solaris/Linux # examine a ,v file, you’ll see they are diffs main RCS commands: cifile # check current version of file in to file,v cofile # check latest version of file out from file,v rcsdiff file #difffile with latest version in file,v demo 3: RCS

10. On a file in RCS you can ask questions like: is this copy the latest “good” version? to which “good” version (created when) does thiscopy correspond, if any? what are the diffs between June 1st and today? is the copy I mailed to Harry older or newerthan the copy on the website? the power of RCS

11. working copy vs. repository the repository (file,v) holds versions of the working copy, but is not a working copy itself no automatic “tracking” of changes in working copies; the user is trusted to check versions in and out as appropriate this can lead to conflictsif multiple working copies are edited version control with RCS: properties

12. only works on single files single host: ci / co work on “local” file system => CVS (written in 1986 on top of RCS) => RCS on a whole directory tree of files at once many extra features repositories can be remote (client/server) nice GUI clients and repository browsers available limitations of RCS; CVS

13. cd ~/bin; cvs log main CVS commands: cvs cifile# check current version of file in to $CVSROOT cvs cofile# check latest version of file out from $CVSROOTcvs up file # id., if a copy is already available cvs add file # put a file under version control in $CVSROOT cvs difffile# compare current copy of file with latest in $CVSROOT file can be a whole directory tree, $CVSROOT can be remote demo 4: CVS for private use

14. cd /tmp cvs –d /home/rp/cvs co scripts cd scripts rightperl bin/* cvs diff # on a different host: cd /tmp cvs –d :ext:rp@svis02.win.tue.nl:/home/rp co scripts # via ssh! demo 4 (continued)

15. a (free) GUI CVS client for Windows easier to use than the command line,but everything works the same way: right-click to get the initial menu, select CVS Checkout ... select the repository and communication method, inside the resulting directory you can CVS update and check in demo 5: the Tortoise CVS client

16. co-authoring papers: one author hosts the CVS repository gives other author(s) read/write access to it software development projects: (demo) petriweb.org: website, software & docs in CVS checked out automatically (using a CVSROOT/feature) demo 6: CVS for collaboration

17. with the :pserver: protocol:- the CVS server runs as one OS user- user accounts are managed in the CVS server- good for read-only access; too insecure for read-write access with :ext: (ssh):- with one CVS server user, slightly better than pserver- with arbitrary repositories for arbitrary groups of people, it requires a lot of account administration (SourceForge: every user can get a Unix account by registering) authentication for remote CVS servers

18. SourceForge ( http://sf.net/ ): over 70,000 CVS repositories (pick one for a demo); mostly software development. Most of the world’s CVS repositories are elsewhere. demo 7: public CVS

19. CVS allows to set up a single repository for all files in a project, with full version control. you always know where your “good” versions areand how they are related multi-user Internet wide (largely) platform independent(on MS Windows you can feel the Unix legacy) the power of CVS

20. working copy vs. repository the repository holds versions of the working copy, but is not a working copy itself no automatic “tracking” of changes; every user must check in and check out regularly;this can lead to conflictsif multiple working copies are edited CVS: properties

21. In the working copy: every directory has a subdirectory CVS/with files used by CVS the file .cvsignore can be used to tell CVS to ignore filesin the working copy that must not be in the repository In the repository: the CVSROOT/ directory contains many files with interestingconfigurable settings CVS administrative files

22. cvs add only prepares to add files, you need to confirm with cvs ci, and on a directory follow that again with cvs up files can be explicitly marked as binary (see the manual) cvs can cope with the difference between Unix and Windows, but if files seem corrupted, check the CVS client settings If you have many conflicts (a working copy has been edited while a new repository version was added from another source) you need to talk to people, not to CVS. CVS caveats

23. creating a repository: cvs init, cvs import branching: cvs tagfile# label current version of file in $CVSROOT cvs rtag # label current versions in $CVSROOT this can be used to create branches, forks of the code cvs merge args # join two branches together (equiv. of patch) cvs edit, cvs editors, cvs watch, etc.: for change notification advanced CVS commands

24. entirely free: no cost, no licensing everybody and their dog uses it: high reliability, good support via Google simple: config files are plaintext, the protocol is simple, source code is free, so it’s very transparent extensible: it’s easy to wrap stuff around CVSat client side and server side(e.g. automatic checkout for petriweb.org: CVSROOT/loginfo calls this script) CVS: strong points

25. overly simple: it works on whole directory trees, but- adding/removing files and dirs is confusing- renaming files isn’t supported (except remove + add)- committing multiple files isn’t atomic- no support for hardlinks / symlinks / shortcuts- tagging/branching whole trees is hard to do the use of diffs:- performance on binary files is terrible- performance decreases with the number of commits CVS: weak points

26. CVS is good when you have a collection of (mostly) text files you change them or plan to change them regularly (at least your copies of them) you and/or others access them from various locations you want to explicitly record and recall “good” versions of the files when to use CVS

27. It does not offer: a website for your project a meeting place / q&a facility for users/authors problem report / task scheduling facilities etc. etc. See again SourceForge for a survey of other facilities required to support a project. CVS only offers version control!

28. no version control:only if you’re sure you’ll only ever need the latest version SCCS (standard on Sun Solaris): not popular enough Subversion and others want to be CVS-like systems that fix its worst problems. I haven’t tried them. Microsoft Visual SourceSafe. I haven’t tried it. more? alternatives to CVS

29. a filesystem copy / backup to another disk or tape: saves everything indiscriminately may or may not save it in a useable state has limited memory for older versions a CVS repository: makes the user decide when to save what expects selective use (not too many files or saves) keeps perfect memory of everything ever saved CVS vs. filesystem backups/copies

30. To learn how to use CVS: you don’t need to know much more than this good manuals are on the Web it takes a few hours to get used to where to go next

31. Is there any need for a departmental CVS server for 1-user projects? (I don’t think so) for collaborations within the dept.? (?) for collaborations with others? (useful, but I don’t see how to set it up) as a public server for material? (?) ? Other kinds of CVS support? (Training?) CVS @ W&I