Korby just promoted (to 'public') a discussion we've had going internally for awhile now - what to call shelve and shelveset. Read up on the feature overview, if you don't know about it yet. I'm the tester 'at the plate' for shelve/unshelve/shelveset testing, so I'm naturally interested in feedback on the naming as well.

 

I personally like shelve/unshelve just fine - as Korby said, descriptive and not overloaded, both of which are key. It's the noun part I can't get happy about - as Doug pointed out, “shelf” won't work because that implies what the stored items are on, rather than the stored items themselves. Shelveset I dislike simply because we're really inventing a word, and we have enough of that going on without adding to it unduly - “incentivize”, “strategery”, “performant” - the list goes on.

 

If it wasn't clear - “shelveset“ is the set of items saved off by a shelve operation, and restored by an unshelve operation. It's sort of a 'Changeset in waiting.'

 

Localization of shelve is a problem, but as far as I can tell, it will be an issue with any of the various alternatives as well - it is, IMHO, both a strength and weakness of English, the variety of words with similar and/or overlapping meanings and connotations. That various words gain additional, or more specific meanings in certain contexts, computing in particular, only makes it worse. At least we'd be inventing a word with a very specific meaning...

 

I saw one comment asking about what happens if the shelveset is stored off and a long time passes before it is unshelved. This is a sample version of a very common scenario:

 

1) User A checks out the latest version of foo.txt, which is currently version x.

2) User B checks out foo.txt also, which is still version x.

3) User B checks in foo.txt, creating version x+1.

4) User A attempts to check in.

 

Clearly, A has to account for the new version. His choices depend on what change he's trying to make, and what kind of change B made - maybe they both simply edited the file; maybe A edited it but B deleted it; maybe A renamed it one way and B renamed it a different way. The resolve command handles all of these issues - some can be handled automatically, some the user must choose an outcome.

 

Shelve adds only a minor twist to this scenario. Suppose that between step 1 and 4, user A shelves his changes. Sometime after step 3, he (or any other user, for that matter) unshelves those changes.

 

When he unshelves, his workspace is updated to have version X of foo.txt, with the shelved changes applied to it. He should then run “get” to catch up to the tip, which might be x+1 or x+100 by now. It may be simple, or it may require several steps, but we do as much as we can to make it clear what has to be done, and prompt you for possible choices in each case. You can also specify some automatic resolutions where appropriate (if content changes can and should be merged automatically, or if you know you want to blow away the changes from x+1 through tip, etc.).

 

So, unshelving version X when the latest version is X+100 won't be easy - but that shouldn't surprise you. It *is* possible, just as branching at version X and waiting until X+100 to merge updates (in either direction) will be possible.

 

Please post suggestions/feedback in Korby's thread, taking into account those he's already listed as possibilities, and those offered up by others. If you like shelve/unshelve and have a good noun for 'the set of items shelved', you'll make my day.

 

If you have specific questions about shelve, resolve, or merge (and while we're at it, diff, delete, status, undelete, and view), feel free to post them here.