通过

Basic operations in Hatteras' cmd line environment - Part 2

  • 项目

Continuing the basic command tutorial, today I'll introduce a couple of more commands: rename, delete, undelete, and undo. Pay attention, because there's a quiz at the end!

Rename - lets you rename or move items within the repository. The command syntax is “rename <src> <dest>“. The source and dest can be either repository paths (starting with $/), or local paths. For example:

    h rename $/killerapp/hatteras $/killerapp/vstsscc

This causes a “rename“ action to be pended to the item “$/killerapp/hatteras“. When you then issue a checkin command for this item, the rename will be committed to the repository. You can also use rename (or more appropriately, it's alias “move“) to move items in the repository. In this example, I'm renaming and moving an item in one step:

    h rename $/files/main.cs $/backups/oldmain.cs

Delete - As its name implies, this command lets you delete items from the repository. But never fear, once they're deleted, you can still un-delete them with the undelete command:

    h delete $/files/main.cs

    h undelete $/files/main.cs

Undo lets you un-pend a pending change, such as an add, edit, delete, etc. You can undo all your changes by specifying a wildcard filespec and the /recursive option (or its shortcut /r). Undo is especially friendly too - if you've actually modified an item, it will by default ask you to verify your intentions before completing the command.

    h undo $/files/main.cs

Update: The quiz question below takes advantage of a feature of the “add“ command I haven't covered yet - implicit additions of parent folders. If you issue an add on a file under a parent folder that hasn't already been added to the repository, that parent folder is also added (just the folder, not its contents). Since Hatteras stores files and folders, this saves you the time of having to issue 2 adds (one for the parent folder, one for the child file).

Ok... So try on your tester hat for a second, and think about what happens if I issue these commands starting with an empty repository:

    mkdir subfolder
    cd subfolder
    echo foo > main.cs
    h add main.cs
    h checkin
    cd ..
    h rename $/subfolder $/folder2
    echo Hello World! > folder2\readme.txt
    h add folder2\readme.txt
    h checkin folder2\readme.txt
    h undo folder2

I'll post the answer tomorrow.

Comments

  • Anonymous
    July 13, 2004
    subfolder
    - main.cs
    - readme.txt

    (the undo wasn't recursive and only referred to the rename of subfolder to folder2)

    Things I'm confused about:
    - Why didn't you need to "h add subfolder" at any point?
    - Does "h" magically know the current path so that when you cd'd into subfolder and added main.cs, it knew that the file lived inside subfolder and not in whatever the current project was inside hatteras?
  • Anonymous
    July 13, 2004
    Good questions. To answer the first, I'll start by answering the second...

    Yes, "h" can tell if the folder you're calling the command from is a working folder or not. Since we are calling "h" from a subfolder of a working folder, it walks up the tree to find the first working folder and assumes you're issuing commands in reference to that. So, when we "h add main.cs", the parent folder, called "subfolder", is implicitly added to the current project. That's why we didn't have to explicitly "h add subfolder".
  • Anonymous
    July 13, 2004
    I'm with Stuart on this one, and, interestingly, I had the exact same question about adding 'subfolder'.

    Although part of me wants a warning to pop-up before that undo takes place, as a result of readme.txt having not been placed in a folder named 'subfolder'. If some other reference exists out there that expects 'folder2', it is going to be orphaned and I'd like to know that fact before I 'commit' to the undo ('commit' sure is a funny word to use to describe an undo!)

    If I had executed these same commands of the course of a week, that warning would be particularly important.
  • Anonymous
    July 13, 2004
    Hmm.. I thought I had blogged about the implicit rename behavior, but maybe that was in a draft I never actually posted. I'll update this post to include a description of how it works.

    Basically, if you issue an add on a file in a subfolder that has not already been added, the folder is implicitly added too. It saves you the time of having to add the folder.