Feature request: temporarily "shelving" work.

[Samuel Jack]

Hi,
I'm often in the situation where, at the end of the day my work is not in a fit state to be checked into our main source tree. However, I do want my work to be backed up in as convienient a manner as possible. How about adding a feature to "shelve" my current changes: that is store them somewhere in Vault without checking them into the main tree?

I guess a workaround might be to use branches. Can you suggest how that would work? Would it place an unreasonable load on Vault? And I guess merging the changes at the end into the main repository might be a bit tricky.

Thanks, Sam

[lbauer]

Using Branch would only branch the files in the repository, and would not back up the files in your working directory.

You could create a folder in the tree called <yourfolder>BAK, and add the files from your working directory into that folder in the repository. This will keep a copy of your modified files in the tree as a backup. Then when you checkin the modified files from your working directory of <yourfolder>, you can delete <yourfolder>BAK.

If you did this very often, though, you'd have a lot of items to obliterate after the deletion.

[Guest]

That workaround doesn't sound as nice as I was hoping - and as you say, places a big burden on Vault.

Any possibility that you can implement a feature like I suggested?

Thanks,
Sam

[jeremy_sg]

I like the feature idea, and will advocate for it for a future release. It's too late to get into 2.1, but it seems like a good concept.

[Justin]

This is a really good feature and will need to go in to be competitive in the future as there are other source controls products that work this way (http://www.accurev.com), and I believe the SQL source control MS is working does this.

It really is a branch, and that could work currently its just kinda cumbersome.

The main concept is that your "working copy" is on the server not in a working folder on a development workstation. That way your working copy is backed up on the server, but another major boon is that your working copy isnt tied to a single workstation anymore you can go home and work there on what you where doing at work yet none of needs to be checked in to the main tree until the developer thinks its ready.

Justin

[christian]

I like the feature idea, and will advocate for it for a future release. It's too late to get into 2.1, but it seems like a good concept.

Hi, for what its worth I think this feature more commonly goes by the name of “private version”. The idea is that part of version control is ring-fenced for a developer to work from, checking in his/her work in progress without making this publicly available to the mainline (the area of the repository shared by developers). When the developer is finished with his task he merges the changes into the public mainline.

I would love this feature for the reasons already posted plus because of a problem that arises when working with shared files. The problem here is say you have a file that's shared between multiple projects, you make changes in one of these projects. Now the only way to make these changes visible to the other projects is to do a check-in. So you're forced into making a check-in when the task at hand is not complete, hosing all the rest of the development team with your work-in-progress that's not tested. With a private version (ring-fenced part of the repository) you'd be able to do a check-in safe in the knowledge that the changes won't be visible to others on the team. Once you've tested the changes you'd then ask version control tool to promote/merge the changes with the mainline. Version control would then work out a change set that is pending against the mainline and do a merge. This also has the benefit in the above scenario that you would only get a single check-in, reducing the noise of all those tiny check-ins just to make changes to shared files visible to other projects.

I agree with one of the posted that this is probably doable by creating a separate branch for each developer but it looks to be a bit clunky.

Do still have this on the to-do list? If so when do you think that it will be available as a new feature?

Thanks in advance
Christian

[jeremy_sg]

I definitely won't be there for 2.1, but I'll push for it in 3.0. I like the idea, but it's a pretty complicated thing that will take a while.

[Thomas Linder Puls]

I can support this feature as well. In fact I will suggest that you consider even more levels.

If we call the first level "private version" then I would call the second level "developer version", and the third level "test candicate" the fourth level "stable version".

The names goes together with this idea (I assume that we are producing software ):

The programmer check in whenever he likes to the "private version". At a certain time he feels ready to commit/promote his changes to the "developer version" to do this he will have to merge with other changes in the "developer version" first.

Developers "Get latest" from their private version and then from the "development version" and then from the "test candidate" and finally from the "stable version".

At a certain point in time it is decided that some part of the software is "good", therefore it is comitted/promoted as a "test candidate".

Somebody will now "Get latest for test", which will get from the "test candidate" and then from the "stable version" (but not from any "private version" or from the "developer version"). This version is then tested. If it pass the test the "test candidate" is promoted to the "stable version".

If it fails it can either be demoted again (i.e. if it was too bad). Or it can be fixed. Fixing at the "test" level will modify the "test candidate" and possibly add (modified) files from the "stable version" to the "test candidate".

Changes made at the "test" level should be merged into the "development version".

The benefit of this is that you have a complete history of stable versions. So you can always "Get the latest stable version" for demonstration of (stable) features, etc. Furthermore, the various "stable versions" you have are excellent candidates to be branched for release.

Ideally you are always ready to branch for release, no matter what development you are currently making.

I think this idea is ambitious and I only think it will work if the tool (i.e. vault) really supports it. The most critical part is how to deal with changes made at the "test candidate" level. Changes here are necessary to integrate new software into the existing stable version. But these integration changes will be made while the development on the development level continues. So there are similarities to having branched. You might say that you have created a lightweight branch.

There is one more thing to this: history. In the longer run you are not interested in the detail history. While working at the "private" level you are interested in a history for that level, but once you promote to the development level the history from the private level becomes uninteresting. Exactly the same happens when you promote to the stable level. Once promoted to stable the history from the development level becomes uninteresting. One stable version is the successor of the previous stable version, how it "morphed" from one to the other is not interesting. And in the end it is your release branches that matters.

[dan]

Thanks for your comments everyone. We will definitely consider doing this in a post 2.1 release.

[Guest]

Hi Thomas,
I like the idea of layering what's in version control based on how the code progresses from private version through to stable release, and that the intermidiate steps (history) after moving from say developer to [acceptance] test becomes non-intersting and therefore noise which should be filtered out.
Christian

[Saturn49]

It seems this feature could also be used for programmer QA. We'd like a simple way to transfer files from a user's workstation into vault so another programmer can look at them and use vault's compare/status search functionality for the purposes of programmer QA. That is, one programmer looking at another programmer's code before it gets officially checked in and grabbed by the compile server which does a "Get Latest"

I'm thinking we might be able to do something like this with labels, and have the compile server grab the latest labeled version instead of "Get Latest". It doesn't work well, however, when expanded to more than a couple developers working on a tree at the same time - project A might be in PQA while project B has completed PQA and needs to get into the build server for testing.

Anybody see any easy workarounds for this with the current version of Vault?

[dm_unseen]

I think most comments in this topic can be seen as Change Management issues

My personal way of dealing with these issues is:

Always check in a file now and then during the day(with empty label!), even if it is still in development and has not been tested, this saves the work centrally when my pc should crash.

Only attach a bug id/track id label(and/or comments) to a file that is ready for production rollout.

This system works very well for me, since only labelled files will be used for builds/deployments. Intermittent check ins will be blank and only intertesting during development/internal testing. For external testing(I don't do that) this would not be enough btw

You can refine this system by adding a status and a track id in a label. So for example adding label "TRCK# 1234 Testing" states this file was made for Bug 1234 and has been used(checked in) in the Testing Phase. Final builds can be made againts labels only containg "TRCK# 1234"(or even add "Production" at then end)

For added safety(or as an alternative) you could share the project branch between a Live/Production, a Testing and a Development branch, by pinning each file on the correct phase. This would alleviate the adding of a Status in the label (which is not very clean).

Moving files form one phase to another would just mean to move some pins to a newer version!

The only bugger you always try to avoid is when 2 different bugs are discovered at the same time, that affect the same files and are handeled by different developers. If you want to allow both developers to code in separation, you cannot get away without any form of branching(even implicit as sugggested), so you would need to create two new shared development project trees, where you branch the files needed for both bugs.

All above in fact describes a typical bugtracking/Change Mgmt/QA System. Most developers that work with such a system will, to be able to cross ref to your VCS, duplicate a bug/track-id# in a label/comment of the files in VCS.

In my opinion Issueing tracking id's and Change Mgmt Statusses should be Dragnet's job, not Vault's. A structural solution would be when Dragnet's tracking id and status can be used transparently by Vault users. The track/bug id would tell the bug being resolved, while the status would tell for which Development Phase the file was meant. The project builder tool needs to be able to handle statuses and track id's/labels accordingly.