Forgot your password?
typodupeerror
Data Storage Software Linux

Home Directory In CVS 414

Posted by timothy
from the good-ideas dept.
shamir_k writes "Joey Hess has come up with an innovative solution to a problem we have all faced. He's put his whole home directory in CVS. Not only can he move between multiple computers easily, he also has automatic distributed backups."
This discussion has been archived. No new comments can be posted.

Home Directory In CVS

Comments Filter:
  • This is innovative but not new, the LJ article is dated September 2002.

    Waky, waky editors?
  • by Rosco P. Coltrane (209368) on Tuesday November 11, 2003 @07:14PM (#7448959)
    Don't forget the -kb switch when you do "cvs add pr0n.avi", otherwise you'll be disappointed when check the file out again.
    • by Anonymous Coward
      CVS will also be a great help when you download pr0n that have the same file names.

      like: untitled.bmp and untitled.bmp - even though they're two different pictures! It'll save the time to rename whole directories!

      And, you can hide all your pr0n from prying eyes too! OOooooo Ahhhhhh!

      Unless, you've named your tree - jerkoff_material.

    • by Vaulter (15500) on Tuesday November 11, 2003 @07:30PM (#7449100)

      "Hold on a minute, I've got to check out this porn."

  • by cuppm (691831) on Tuesday November 11, 2003 @07:14PM (#7448967)
    Man, I have a hard enough time trying to get them to accept my insurance card for prescriptions. Hats off to him for getting them to take his files...
  • by Beryllium Sphere(tm) (193358) on Tuesday November 11, 2003 @07:14PM (#7448968) Homepage Journal
    /etc

    Have a checkin comment for why a configuration change got made. Be able to roll back a failed experiment reliably. Find out when a change happened.
  • I wonder..... (Score:5, Interesting)

    by The One KEA (707661) on Tuesday November 11, 2003 @07:15PM (#7448977) Journal
    Has anyone tried this with BitKeeper [bitmover.com]?
    • Re:I wonder..... (Score:5, Informative)

      by Kourino (206616) on Tuesday November 11, 2003 @07:22PM (#7449030) Homepage
      You wouldn't do this in Bitkeeper if you were a privacy freak. Remember, the Bitkeeper liscense requires that you maintain open logging. Realistically, this means that info about what files you change get transmitted across the network; I don't know if it's encrypted or not. It's not that big of a deal, but I'm sure someone here would care.

      That being said, doing it in BK would be a compelling alternative if you wanted to use the same /home repo across (say) three or more machines, since you could take advantage of its more complex merge operators. Arch or SVN also might be good ideas. (Don't have any experience with Subversion, though.)
      • Re:I wonder..... (Score:3, Informative)

        by Otterley (29945)
        Wrong. BitKeeper does not require open logging for single-user, single-host repositories.
  • Why just home? (Score:5, Interesting)

    by AuMatar (183847) on Tuesday November 11, 2003 @07:16PM (#7448979)
    I asked this on a local linux mailing group recently- what do people think about the idea of a version control file system? Disk space is cheap these days, we can afford it space wise. Think of all the problems it would solve.

    *Made a mistake in your config file? Revert it
    *User deleted the file? Revert it
    *Want to see why you made a change to any given file? Check the comments (commenting would be optional, of course)
    *Your system was exploited? Revert the entire system to before the exploit
    *Upgraded an app and regret it? Revert the files

    And so on. I'm not sure if CVS would be the best method (I'm not a SCM specialist), but I'd see this as an extremely useful feature who's time has come.
    • Re:Why just home? (Score:4, Informative)

      by PhilipPeake (711883) on Tuesday November 11, 2003 @07:23PM (#7449033)
      Ever hear of VMS ?

      It had a filestore with file versioning - about 30 years ago.

      • Before my time. Heck, before my birth (I've hear of the OS, but never experienced it). Perhaps its time to revive that feature, then.
      • Re:Why just home? (Score:3, Informative)

        by Jim Hall (2985)

        Ever hear of VMS ? It had a filestore with file versioning - about 30 years ago.

        Not just VMS. Apollo DOMAIN had something like this, too. -jh

      • Re:Why just home? (Score:4, Informative)

        by bug-eyed monster (89534) <bem03@can[ ].com ['ada' in gap]> on Tuesday November 11, 2003 @07:46PM (#7449232)
        It's been quite a while since I used VMS... IIRC the problems we had we the VMS versioning:

        - It created a new version every time you saved, so just going through a few change/compile/fix cycles (for example) would create lots of versions clogging up the disk.

        - The old versions were in the same place as the latest version, and if you wanted to delete a file, you'd just say "delete blah.blah.*" to wipe out all versions (and therefore all traces of the file)... then say "oops!"

        It was useful in many cases, but in a different way from CVS. A very useful solution would be to have file-level journaling with the ability to throw in comments and create tags and branches.
    • Re:Why just home? (Score:5, Informative)

      by Jellybob (597204) on Tuesday November 11, 2003 @07:25PM (#7449056) Journal
      I'll get modded down to oblivion for mentioning an MS product in a positive light, but Windows XP+2003 Server supports this already.

      Users can rollback to previous revisions of files that they've saved to the 2k3 server, saving the sysadmins the time of restoring *another* accidently deleted file from the backup tapes.
      • Hasn't Novell had this functionality for years?
        • Very possibly - I wouldn't know though, since I work is an MS shop, and home is Linux based.
        • Salvage is your friend. Of course they may have change it's name or removed it, it was salvage back in 4.1.
          • Hmm... and then there was purge, to reclaim all that used diskspace. IIRC, you ran "purge -all", and suddenly all those embarrassing filenames that you thought were safely deleted run across the screen while your SO is watching over your shoulder... Great way to learn how to quickly switch to another DesqView screen :)
        • Yup. At least since 2.15 when I first used it. It's called "Salvage". The only thing that sucks is that if you delete the actually directory structure (not just files within) then they get dumped into one huge list. So if you had a folder with ten subfolders and a hundred files in each one you would have to manually eyeball a list of those 1000 files plus every other file whose parent folder had been deleted.
          Worked great 90% of the time. The other 10% or so it was easier to just go to last night's
      • What? Like VMS?

        (ducks)

    • If I'm not mistaken, MS is trying something like this with their Filesystem for LongHorn (the enterprise edition).

      Not too sure, though.
    • Re:Why just home? (Score:5, Insightful)

      by pclminion (145572) on Tuesday November 11, 2003 @07:26PM (#7449069)
      The basic problem with versioning in the file system is deciding when to commit. Do you commit for every byte written? Of course not, that would be a massive waste of time and disk space. Do you commit once for every write() call? That suffers the same problem, because sometimes writes are very small, and you can never predict in advance how large a write will be.

      You can't automatically commit after every xxx bytes of data written, because that means there will be a bunch of intermediate states on disk, most of which are probably bogus (this argument applies to the above two options as well).

      The only thing that even remotely makes sense is to commit on close(), but that doesn't make sense for applications like text editors which keep the file open for the entire duration. You want each SAVE to be a commit, not each CLOSE.

      What this boils down to is that there must be application level support for the commit operation (i.e., a new commit() syscall). The application has to specifically be coded to tell the operating system "Ok, I'm done with the revision, commit this now." And that means every application on the system will have to be tweaked to make the necessary commit calls, not to mention the thought that goes into deciding WHEN it is appropriate to commit. I would wager that a lot of maintainers wouldn't bother to make those changes, and as a result those applications wouldn't support versioning.

      I agree that a versioned file system would kick ass, and there are even some out there already (Google for "versioning filesystems"). But they tend to be special purpose. I don't see how it could be cleanly and transparently integrated into a general purpose system such as Linux.

      Note that I didn't bother to check CiteSeer to see if there is academic work on this before posting this comment. So if anyone knows of any work toward that end, I'm sure a lot of us would appreciate a pointer to it.

      • Hmm. But a save would be a commit with a save on close. Look at the disk API- fopen, fread, fwrite, fseek, fclose. THere is no fsave. To do a save, you open the file in write mode, write the data, then close it every time. So that would work. You would have more commits than necessary (for those of us who save every few minutes), but thats better than too few.

        We would, however need a new system call close_with_comments that comments a commit (the old style close would not comment, thus allowing back
        • Re:Why just home? (Score:5, Informative)

          by AuMatar (183847) on Tuesday November 11, 2003 @07:37PM (#7449156)
          To make this more legible- a text editor, for example, does not have the file open the entire time waiting for input. It opens the file, reads it, then closes it at startup. When the user hits save (through keyboard commands, mouse click, whatever), the editor opens the file again, this time in write mode, writes the data, and closes it. By this model, close could be the commit function, and open could be the checkout function.
      • Committing on both "commit()" and "close()" should work; for old-style applications that don't support "commit()", this will ensure that successive versions are whole versions, but won't commit as often as you might like. For apps that support commit(), a commit() followed by a close() would only commit one version. For filesystems that don't support versioning, commit() would be a no-op.
      • Re:Why just home? (Score:2, Insightful)

        by cpghost (719344)

        This is the reason database transactions exist. A filesystem based on CVS would need the concept of (atomic) transactions: you open(2) the file, therefore starting a transaction. Every access (read(2)) and modification (write(2)) etc... goes in the transaction _only_, and at close(2), the transaction gets commited.

        The funny part starts at close() (or commit())-time, when you need to resolve conflicts. Huh...

      • Why not just commit on both close() and commit()? This way all apps support versioning, and an app that can make better use of the commit() call can be updated to use it.

        Or if the OS was really smart, you could configure it to commit on save() or close() depending on the application.
      • How about using a journaled file system? They keep a log of recent writes and what not. So every time you commit the log, a new version is made. It'd be like a meta log. Which probably means it would suck =(
      • Re:Why just home? (Score:5, Interesting)

        by bcrowell (177657) on Tuesday November 11, 2003 @11:56PM (#7450720) Homepage
        The basic problem with versioning in the file system is deciding when to commit.
        I use Unison [upenn.edu] for this, and it works great. A commit happens whenever I choose to run Unison. I'm a human. Unlike a computer, I understand what I'm doing and why. I know when I'm done working on something, and when I'm ready to synchronize my files.

        From the article:

        • I get three major benefits from keeping my whole home directory in CVS: home directory replication, history and distributed backups.

        I get all these benefits from Unison. Admittedly, the history only gives me snapshots at two different times (time 1=now, time 2=last time I committed), but that's always been good enough for me. Deleted the wrong file? No problem -- get it back from the other machine.

        Unison is also cool because, unlike CVS, it (a) is easy to set up and maintain, (b) is quick and easy to run, and (c) works just as easily with binary files as with text files.

    • Yeah, I agree. And so does Hans Reiser BTW, it is on his list of things to put into the Reiser file system at some point. (And if you want to make it a high priority item pay him to do it :)
    • IIRC, Hans Reiser said in an interview some time ago that versioning is on his (very long) list of things to implement in ReiserFS when it's done - so he's with you there, saying this should be part of the file system. I sure think it'd have interesting applications!
    • I'm very surprised that no one has mentioned this already, but this was done years ago.

      I'm by no means an OpenVMS expert, so if there's one in the house please feel free to correct me.

      At a past client (nearly seven years ago) I recall staring in awe when I learned some of the details about the VMS filesystem. Filenames were appended with a colon, followed by a number (for example, "README.TXT;5"). The number after the colon represented the version number.

      Accessing the filename (without the colon or versi
    • I asked this on a local linux mailing group recently- what do people think about the idea of a version control file system? Disk space is cheap these days, we can afford it space wise. Think of all the problems it would solve.

      Windows does this. It's called "system restore".
  • by Anonymous Coward on Tuesday November 11, 2003 @07:17PM (#7448990)
    ... quick, patent it!
  • Sourceforge (Score:5, Funny)

    by Smitty825 (114634) on Tuesday November 11, 2003 @07:18PM (#7449003) Homepage Journal
    I'll put my home directory on Sourceforge! Everyone can now help me maintain it!
  • by Anonymous Coward on Tuesday November 11, 2003 @07:18PM (#7449008)
    'cause CVS loses the history in these operations.
  • CVS, eh? (Score:5, Informative)

    by Kourino (206616) on Tuesday November 11, 2003 @07:19PM (#7449010) Homepage
    I wonder why CVS, and not something more advanced, like Arch [gnu.org] or Subversion [tigris.org]? Especially since he outright complains about common limitations in CVS, like moving files and dealing with directories at all. If he's hoping, as he says, "for a better replacement some day", why not see what the present has to offer?

    I mean, that's not to say that alternative systems are perfect, either. I'm going through the process of learning arch now. There's a learning curve, but not nearly as big as it's made out to be. Still, using something else (almost anything else) would probably help on things like the merging issues, especially since he mentions that sometimes it's a pain keeping things in sync between three of his machines.
    • I'm going to guess, and say it's because CVS farm more is likely to be installed on a given machine. I could be wrong.

      --Mike--

    • Re:CVS, eh? (Score:5, Informative)

      by self assembled struc (62483) on Tuesday November 11, 2003 @07:30PM (#7449104) Homepage
      well,

      have you every tried to install and set up subversion?

      plus, after years and years of development, it's still point-oh-something and specifically states they can only guarentee that your repository can be read with x number of versions after the version that created it.

      as for arch, i've been looking into it, but it's still a hack onto cvs.

      subversion gets some of it right, but at my old company we used perforce and honestly, i'm spoiled and i've been trying to find a free (just as in beer, free as in speech would be nice, but i just want to get my work done quickly and without hassle) source control client that can mimic the functionality and stability of perforce, and i've yet to find one.

      too bad my new place won't shell out the $650/seat for the license...
      • Heh. I have heard that Subversion archives are just awful to get set up right.

        How do you mean that "arch is a hack onto CVS"? (I guess I had forgotten about archive format stability, though.)
      • Aegis (Score:3, Informative)

        by axxackall (579006)
        Check this version control comparison [berlios.de] for more options.

        Personally I prefer Aegis [sourceforge.net]. It's a bit more complicated to use than CVS (well, aegis is MUCH easier to install than subversion), but takes care about way more situations for you.

      • Re:CVS, eh? (Score:3, Informative)

        by pHDNgell (410691)
        as for arch, i've been looking into it, but it's still a hack onto cvs.

        WTF are you talking about? Arch is only related to CVS in that it's in the same application category.

        i'm spoiled and i've been trying to find a free (just as in beer, free as in speech would be nice, but i just want to get my work done quickly and without hassle) source control client that can mimic the functionality and stability of perforce, and i've yet to find one.

        We use perforce at work and I'm fed up with the lack of functio
      • Re:CVS, eh? (Score:5, Informative)

        by vslashg (209560) on Tuesday November 11, 2003 @08:19PM (#7449505)
        I agree that Perforce is awesome. But here's something you may not know -- Perforce is completely free for the kind of thing this article is talking about doing.

        Specifically, Perforce is available for download here [perforce.com]. Without a license, it only supports two users and two clientspecs... not enough to manage a project shared among developers, but wonderful for managing your code in home projects. More good news: Perforce is free-as-in-beer for use in developing open source projects [perforce.com].

        (This isn't meant as a holy war... I know that many of you might think that source control package Foo is better than Perforce. You may be right. I'm just pointing out some Perforce licensing facts for those who like Perforce.)
      • Re:CVS, eh? (Score:5, Informative)

        by aardvarkjoe (156801) on Tuesday November 11, 2003 @10:07PM (#7450138)
        have you every tried to install and set up subversion?

        Subversion is pretty easy to install and set up as long as you don't use the Apache interface. It's pretty much just a matter of downloading the subversion and libdb archives, and doing "./configure; make; make install". I've never had any problems with it, and it is rapidly approaching version 1.0.

        One of the main things that they ought to make clear is that the http interface is a nightmare to set up -- with the exception of making publically-accessible repositories, using the svnserve method over ssh is a far better choice.
    • Subversion

      The article was written in September 2002. SVN was at 0.14 then.
    • Re:CVS, eh? (Score:2, Informative)

      by retinaburn (218226)
      If you look at the bottom of the page, he does in fact say that he uses Subversion. He just hasn't updated the article to show this.
  • Isn't this the sort of plug-in thing that Reiserfs is supposed to make a lot easier to do at a fundamental level ?

    As I understand it, you register callbacks on the atomic operations of the FS, and your code gets run with appropriate parameters before/after whatever. A bit like SQL triggers...

    Simon.
  • by DrSkwid (118965) on Tuesday November 11, 2003 @07:21PM (#7449023) Homepage Journal
    Plan9 has the mantra : "file creation is forever"

    Automated incremental backups are a way of life.

    With Venti [bell-labs.com] one can even back up two windows/linux machines and *not* use up disk space for commonly used blocks, so backing up 100 machines wont use up the usual 1Gb each for the duplicate libs/windows directories.

    The yesterday [bell-labs.com] command give you the power to browse back through your life

    Find what has changed in the C library since March 1:

    yesterday -d -0301 /sys/src/libc/port/*.c

    When did you say this guy did the innovation again?
    • by Rosco P. Coltrane (209368) on Tuesday November 11, 2003 @07:39PM (#7449180)
      Right, so on plan9, you can recover all your previous file versions, for example, letter_to_boss.txt :

      v1.0: "You stupid fuck, why don't you give me a raise some day?"

      v1.1: "You tight-pocketed capitalist, isn't it high time you gave me a raise?"

      v1.2: "Hey Boss, I really think I deserve a raise, I've been working on this project for so long."

      v1.3: "Hello Boss, I respectfully request that you should consider giving me a raise, as I think have proven to be a reliable, hard-working employee. Please?"

      v1.4-FINAL: "Dear Mr. Schmoe, I wish to apologize in advance for stopping work on our most important project for five minutes, but I would like to present an idea to you : you see, ever since I have started working at 6-pack computing, I've tried to be a model employee and ... ... ..."
  • Oh I like that (Score:4, Insightful)

    by The Munger (695154) on Tuesday November 11, 2003 @07:22PM (#7449028) Homepage
    That's a smart way of doing things. I've found version control to be worthwhile on even single user projects. Having the same kind of backup/restore and history tracking on every one of your files just makes sense. I'm suprised no-one has done this sooner.

    In a slightly more abstract sense, it provides a 'working set' of documents on your computer. Comments on your version history adds meta-data to files that is time-based. Most systems at the moment add meta-data that is for the current file. Imagine, you check in some files with a comment like 'Project: holiday snaps 03'. Then later on, you use one of those files in a presentation 'Project: report for Bill 03'. With standardised formatting of such tags, the file keeps with it the idea that it has been used with multiple projects at different times. That's a powerful method of grouping.

    Ever been in the situation where a file belongs with multiple projects? With your standard directory structures, you might put it in one directory and shortcut/alias/whatever it in the other (or maybe make a second copy). It's pretty ugly right? What if you could say, this file belongs to both of these projects, and you could even provide the old version that was used in another project. OK, so all of that would require some more automation - we can dream can't we?

    That has a lot of possibilities.
  • ssh private keys (Score:2, Insightful)

    by smcavoy (114157)
    somehow I don't like the idea of my private ssh keys being sown like a seed across a number of systems.
    To much of a headace worrying about where they are, were they deleted properly... etc.
  • by adamfranco (600246) <adam@adamfranco.cBOYSENom minus berry> on Tuesday November 11, 2003 @07:27PM (#7449087) Homepage
    I currently store parts of my .thunderbird and .phoenix directories in CVS and do the commit/update to sync work and home. In general it works pretty well, though not all my settings translate well between OS X (work) and Red Hat (home). For this reason in particular, extensions are not in my CVS and this makes keeping stuff custumized a bit of a pain still.
  • by penguin7of9 (697383) on Tuesday November 11, 2003 @07:33PM (#7449127)
    My recommendation: use the Unison file synchronizer [upenn.edu] to keep multiple copies of your home directory in sync.

    It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning. On the other hand, it is symmetric (meaning, none of the copies are distinguished) and it is much less hassle to use. Also, you can define custom merge methods to automate merging of things like mailboxes. Unison is great for keeping a home directory (or portions of it) in sync between different desktops, and between desktops and laptops.

    Note that for live backups, rsync is probably still the best choice because you want something unidirectional.
    • The problem with file synchronization that is solved by CVS and not by unison is that cvs will merge your changes. This keeps you from being locked out of a file at home that you know you've changed at work and forgot to commit. I'd love to see more file synchronization that can merge the content rather than just move files around as a whole.
    • It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning.

      That's actually the key feature here. Unison is great if you want to have just the most recent copy available. Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too. However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right las

      • Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too.

        No, it cannot. rsync is a uni-directional file synchronizer and it doesn't have an interactive interface. unison is a bi-directional file synchronizer with non-timestamp-based change detection and a GUI for resolving conflicts. The two are completely different things. unison does much more than rsync.

        However, versioning allows you to go back to the most useful prior version of the file, not just the mos
  • I remember reading this article over a year ago when it came out. CVS is nice, but it doesn't handle directories well. IIRC, he mentions this.

    I've recently started using rsync kinds of scripts along with cron. It doesn't keep history, but it makes syncing really easy. If you need history, make daily backups. Additionally, rsync is slightly better at lower bandwidth usage vs full blown CVS.

    As for ssh keys (as someone here mentioned) you can have CVS and rsync ignore specific directories you don't want
  • by Henry Stern (30869) <henry@stern.ca> on Tuesday November 11, 2003 @07:55PM (#7449318) Homepage
    I shudder to think what happens when he tries to rename his files and directories.

    Definitely the biggest problem with CVS. :(
  • by joey (315) <joey@kitenet.net> on Tuesday November 11, 2003 @08:01PM (#7449358) Homepage
    I'm not sure why something that I wrote in 2001 and that appeared in print media in 2002 is news.
    This is the second time I've been slashdotted for something over 1 year old this year. Previously it was the pkg-comp page, which I wrote circa 1998.
    Kinda makes you wonder.

    Anyway..

    I suppose I should mention that these days I keep most of my home directory in subversion. I have not gotten around to writing a successor to this article yet, but it works even better than cvs, and that's probably the most common question people ask me about this article these days.
  • Hmm, didn't Microsoft's lawyers patent innovation? Or will this, since it's made with GPLed software that obviously (by Bill's standards) hinders innovation, force a rip in the space time continuum and send us all to an alternate Universe where up is down, down is up, cats and dogs live together, and Microsoft actually invents new technology instead of buying it?
  • iFolder [novell.com], for those that don't know, is Novell's distributed folder. Work done on any computer is synchronized with a server and automatically distributed and backed up to all other clients authenticated as the same user and running the iFolder client. A simple concept that proves decidedly valuable.

    I attended a conference, today actually, about Novell's jump into Linux and iFolder was stressed again and again as an excellent cross platform synergy device. I was thinking through the whole conference that
  • I wonder what his comments look like.
    ---

    Nov 10, 2003. Deleted old porn from pictures directory. Replaced with new, better, porn.

    Nov 11, 2003. Added 'Animal House' soundtrack to the music directory. Added additional porn to the pictures directory.
  • by Polo (30659) * on Tuesday November 11, 2003 @08:31PM (#7449586) Homepage
    Did you see his followup reply at the bottom??
    Re: CVS homedir (Score: 0)
    by Anonymous on Tuesday, November 11, 2003

    I suppose I should mention that these days I keep most of my home directory in subversion. I have not gotten around to writing a successor to this article yet, but it works even better than cvs, and that's probably the most common question people ask me about this article these days.

    -- Joey Hess
  • by Anonymous Coward on Tuesday November 11, 2003 @08:45PM (#7449674)
    I've been keeping my home directory in CVS since 1996. Prior to that, I kept it in RCS, since around 1985, and briefly in SCCS.

    I haven't yet decided to go to Subversion, in part because I have a patched version of CVS that allows me to check into multiple CVS repositories - i.e. I can check in when on my laptop on an airplane, disconnected from the net, and can later check in to my main repository when I get connected. (Yeah, yeah, BitKeeper is a way to do that.)

    As Joey's article discusses, there are minor issues with CVS'ing your home directory: use of modules, etc. I divide it into stuff that is owned by the company that I am currently working for, and stuff that I own.

    When I get an account on a new machine, one of the first things that I do is create a new branch (or, a new version on some existing branch) to hold the dot files and other files
    that were pre-installed in my home directory. Having saved them, I then blithely overwrite them with my standard home directory, and maybe do a quick check to see if there are any special features worth propagating to my standard home directory.

    Oh, yeah: a bit of footwork to checkout
    onto your home directory:

    cd ~
    mv * .* /tmp/glew/old-home-directory // actually, usually saved already
    cvs -d MYSERVER co glew-home
    mv glew-home/{*,.*} .
    rmdir glew-home

    I often find myself pasting together
    modules from different repositories.
    Sometimes I *want* a "cvs update"
    in the root, e.g. in ~, to traverse
    repository boundaries - no problem.
    But sometimes I don't - e.g. I frequently
    work in ~/hack, and check out stuff into there.

    To do this, I have fallen into the habit
    of creating a CVSBARRIER directory that is
    not checked in, that prevents cvs update
    from traversing.

    Also, I find it useful to have a place
    to put overall comments for a repository.
    Typically, this is ~/README or ~/CVS-status.
    The overall comments - such as "the tag
    named FOO is my home directory at the time
    I moved to university BAR and merged in
    changes from my laptop BAZZ that had diverged"
    get suck in the CVS log, via
    cvs ci -f CVS-status.

    Oner thing: when yiou have as much history as this, you notice when programs change their interface. E.g. nmh doesn't run my ~/.mhrc from 1994 :-(

    --- Andy "Krazy" Glew
    (I'm too lazy to create a slashdot account)
  • Rsync anyone? (Score:3, Insightful)

    by pico303 (187769) on Tuesday November 11, 2003 @09:44PM (#7449980)
    Isn't this what rsync is for? CVS seems to be the wrong tool for this job.
  • Old news (Score:5, Informative)

    by whereiswaldo (459052) on Tuesday November 11, 2003 @09:57PM (#7450060) Journal

    This was featured in a Linux Journal article from September 2002:

    http://linuxjournal.com/article.php?sid=5976

    Same guy, too.
  • by negyvenot (582011) on Wednesday November 12, 2003 @04:05AM (#7451606)

    rcsvi is a simple wrapper for vi that puts edited files under revision control. It does not support any vi flags. It only takes one file argument and an optional revision number for reverting to previous versions. A few examples:

    # alias vi=rcsvi
    # vi /etc/passwd
    [ remove Agent Smith's account ]
    :wq
    /etc/passwd: 12 lines, 94 characters.
    enter log message, terminated with single '.' or end of file:
    >> Agent Smith's account removed.
    .
    Voila. You now have your passwd file under revision control. More examples:
    # vi -r1.2 /etc/passwd
    # rlog /etc/passwd
    # rcsdiff -r1.2 -r1.3 /etc/passwd
    To make a complete backup of your system configuration:
    # tar fc /tmp/RCS.tar $(find / -type d -name RCS)
    Now you may ask "ok i want to edit multiple files and/or do some other trickery". Don't. It's a simple tool, that i'm using for years now with great satisfaction.

    Check it out here [freshmeat.net]

I came, I saw, I deleted all your files.

Working...