Jump to content

Shelving Check-outs


CodingGorilla

Recommended Posts

Posted

Another question: At some point during the beta for 4.0 I remember reading about the ability to "Shelve a checkout", which as far as I remember, meant basically that you could switch from a branch that had changes, to a different branch without the need to actually check-in the changes.

Was this something that was removed? Just curious.

Posted

That IS a function in 3.0, discovered it by accident one day lol (not sure if ya'll have used 3.0). May be one of those things they haven't had a chance to incorporate in 4.0 yet?

Posted

I don't want to speak for the Plastic team and how they are going to implement this feature, but in Git it's an explicit command to "stash" any local changes without committing them so you can have a neat and tidy workspace before switching to a different branch. I think (never worked with it) in 3.0 it would just do this behind the scenes, and when you went back everything would be there. In Git you need to either check it in to source control or stash before you can switch or you would lose any changes.

Posted

Exactly: it will be optional: you can "stash/shelve" your changes. There are a few differences with 3.0, though.

- 3.0 shelved all checkouts to the server, automatically, so the new "configuration" was clean

- 3.0 reloaded the shelved changes when you switch back to the branch

That's what we want to have on 4.0 but:

- We're not sure yet whether we'll shelve the changes on the server or the client

- We'd like to be able to "shelve"/stash more than one intermediate version

- We'd like to use it to implement "selective checkin" (where you can decide some lines/changes not to be checked in while kept on the working copy)

- We'd like to shelve/stash a set of changes (all checkouts, or all related ones) and then be able to "apply then" (cherry-pick then) to a new branch (instead of just shelving/unshelving as 4.0 does)

- We'd like the list of "shelves/stashes" to be explicit and manageable by the user (it was totally automatic and transparent in 3.0)

Posted

I really don't know why I want these features so much because my workflow hasn't been worse without them, but as I read your list I started to get anxious wanting them like yesterday.

These are great examples of quality of life feature sets. I can do my work without them and maybe I wouldn't even miss them, but having them around to use when you need to could be invaluable.

Posted

@carpediemevive XD

They'll definitely be exciting... and they're only a subset of the new features we're cooking. 4.0 is an excellent base to continue growing...

We'll be reworking the update operation soon:

- adding progress (long awaited)

- greatly reducing memory usage (it is a must for huge codebases, and believe me we're dealing with >300k files on a single workspace more often than not)

- reducing network usage

- making it faster for small updates (it is fast now for huge updates, but the time for small ones can be improved)

- making it share its foundation with the merge... (yes! you read right... :P)

Posted

Hi Pablo and gang,

For update operation (and maybe others) have you / would you consider creating log file(s) to record the update results?

In 3.0 GUI, you can open the Plastic Log pane and get log of what was updated, which can be copy 'n pasted to a file, which covers it pretty well.

But, if you do the update from the Windows Explorer interface, you don't get that feedback (unless you read the progress dialog box real fast). :)

For my local workspaces I generally use the GUI, but I have also created a workspace on a network drive so those that are Plastically-challenged can view controlled files. For the network workspace, I always do updates via Windows Explorer, so I can never say for sure which file(s) were updated as a result.

Just another item for the wish list.

Thanks as always!

Dean

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...