Freigeben über


Basic operations in Hatteras' cmd line environment - Part 2 Answer

Here's the answer to yesterday's quiz. I'll work through each step and describe what's happening:

1. mkdir subfolder - makes a folder on your local drive
2. cd subfolder - change directories into the folder
3. echo foo > main.cs - create a new file under “subfolder“
4. h add main.cs - pend an “add“ action to the new file
5. h checkin - checks in both the file and the folder “subfolder“. This is the implicit add behavior I mentioned in yesterday's blog
6. cd .. - change directories up 1 level
7. h rename $/subfolder $/folder2 - pends a rename of “subfolder“ to “folder2“
8. echo Hello World! > folder2\readme.txt - create a new file under “folder2“
9. h add folder2\readme.txt - pends an add to the new file under “folder2“, and an implicit “add“ on folder2
10. h checkin folder2\readme.txt - checks in folder2 and readme.txt
11. h undo folder2 - Trick question. At this point, there is actually nothing to undo for the item “folder2“. folder2 was added for you in step 10.

Unfortunately, I think I probably made this sample a bit more complex than necessary to get the point across about implicit adds. It also turns out I found a bug while going through this exercise ;) The implicit add of “folder2“ seems to have eaten the rename of “subfolder“, so after the checkin in step 10, your local drive arrangement doesn't match the repository. I'll make sure that gets fixed. Such is the life of a tester... 

If you have questions about what would happen after a certain sequence of commands, please ask. I'll do my best to answer!

Comments

  • Anonymous
    July 14, 2004
    Hmm, I definitely think I want a warning when checking in a file will implicitly check in its parent folder.

    Does the implicit checkin behavior go all the way up the tree? Consider the following case:

    mkdir folder1
    cd folder1
    mkdir folder2
    cd folder2
    echo hello > test.txt
    h add test.txt
    h checkin readme.txt - checks in all the way up
    cd ....

    (now the tricky part)

    h rename folder1 topfolder
    cd folder1folder2
    echo hello world > test.txt
    h checkin test.txt

    Does the rename of folder1 get checked in even though there's no pending change on folder2?
  • Anonymous
    July 14, 2004
    I agree with you on the warning. I was discussing this and some other implicit behavior type issues with James Manning this morning, and we both think more feedback to the user is warranted here.

    The answer to your first question is yes. The implicit folder add happens all the way up to the root ($/).

    In your second example, I think you probably wanted to insert an "h add test.txt" after the echo step. When you issue that final checkin, topfolderfolder2test.txt is added, including the folders, and the rename you pended is "eaten". So, items that previously existed in folder1folder2 that WOULD have been moved/renamed still exist in the old location. You've hit on the same bug I alluded to above ;)

    Thanks for the questions! I appreciate all the convoluted and wacky cases you folks can come up with - it helps me make sure we're covering everything we need to be in our testing.

  • Anonymous
    July 15, 2004
    The comment has been removed
  • Anonymous
    July 15, 2004
    The comment has been removed