CodingGorilla Posted December 21, 2011 Report Posted December 21, 2011 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.
carpediemevive Posted December 21, 2011 Report Posted December 21, 2011 I ran into this yesterday during pure experimentation. I don't really have a need for the feature, but I echo the interest.
deanaug Posted December 21, 2011 Report Posted December 21, 2011 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?
manu Posted December 21, 2011 Report Posted December 21, 2011 Hi guys! the shelve operation is not ready for 4.0, it will be, but I can't estimate when.
CodingGorilla Posted December 21, 2011 Author Report Posted December 21, 2011 That's fine manu, it was more of a curiosity for me. It sounds like a cool feature, another one I can use to push the product to my team, but I have no immediate need for it.
psantosl Posted December 25, 2011 Report Posted December 25, 2011 We are designing a new shelve feature, but closer to the git stash. What do you think?
carpediemevive Posted December 27, 2011 Report Posted December 27, 2011 I would love to see it. I'm not in dire need of the feature now, but it certainly would be fun to use when I do have it.
CodingGorilla Posted December 27, 2011 Author Report Posted December 27, 2011 I'm not all that familiar with Git, can you describe it?
carpediemevive Posted December 27, 2011 Report Posted December 27, 2011 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.
psantosl Posted December 29, 2011 Report Posted December 29, 2011 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)
carpediemevive Posted December 29, 2011 Report Posted December 29, 2011 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.
psantosl Posted December 29, 2011 Report Posted December 29, 2011 @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... )
deanaug Posted December 31, 2011 Report Posted December 31, 2011 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.