How to rollback entire change set?

[arden_dan]

I don't know if this feature is still on a list somewhere, but I would like to be able to do a History by Version on a project and rollback to the previous version. It would be handy for those times when somebody doesn't understand the term code freeze

If it's still there, just add my vote.

Thanks.

[lbauer]

Yes, this was requested a while back. I'll add your vote to the feature request.

[christian]

Can you add another 10 votes from me ;-)

Christian

[lbauer]

Na, only one man/woman, one vote here.

[christian]

Well it was worth a try :-)

[Azteki]

Would it be possible to:

through the history browser branch the earlier version before the last update
then re-merge the new branch (which is nothing but the previous version)

And that would function like a group rollback?

-Azteki

[jclausius]

In a not so round-a-bout way you could :

1) Run a History query to get the filter out the historical items.

2) Checkout out the files to disk from History Explorer.

3) Once you've verified the versions are correct, touch the files to update the timestamp.

4) Finally, check in the rolled back files.

[daboy1216]

Rollback changeset: +5 votes (We've got 5 guys on our team!)
Change description to "View folder history by changeset": +1 vote (To be honest, I didn't even know that this was there until the post above, because I didn't understand why the folder version was important.)
Put rollback changeset on "View folder history by changeset" dialog: +1 vote (I definitely think that's the right place for it, but I also think it might work in the "Version Details" dialog that shows what files were part of the changeset. I've always kind of visually associated that dialog with the conceptual object that is a "changeset".)

Thanks!

[mlippert]

I've just had 2 people come ask me to help them rollback a changeset. I had to tell them that they had to rollback each file in the changeset individually.

Of course they then said "so what's the advantage to checking all of the files in together in 1 changeset", which ignores the myriad other benefits of changesets, but is a pain to hear when I've spent some effort convincing people of the benefits of changesets.

So add my vote for rolling back changesets, and is this by any chance (pretty please) on the radar for 4.0?

Mike

[Marc]

This is one of the more common roadblocks I run into. Right now I'm in the middle of a 100+ file rollback.

Toss my name into the "really wants this" hat.

[lbauer]

You're in. I'll add your "votes."

[nroberts]

add mine too, thanks.

[Dmitri Shvetsov]

Sorry, that isn't available yet. It is on our feature list though - thanks for the request.

I'd like to request this feature as well. It's extremely important for the development. We're using Vault 2.0.6 (2219) and we have to branch the previous releases to a separate directory. Keeping in mind that the solution has about 30 very busy projects and this is a web project with many relations, it's not easy even to branch it keeping the entire consistency. That's the worst way of doing that for the development because each time when we need to fix some bug that we found in the published release we need to replace the entire directory with the source code and work with it, then merge the changes with the latest code manually using Araxis Merge and finally switch back to the latest version of the code. Brrrr.

It would be nice if we could sync all latest files with the server, then retrieve the code from the SG server on some date/time, actually the date/time of the latest release. The SG should store somewhere that the files downloaded from the server are not actually the latest ones, maybe right in the file headers, we have the header in each file showing the date/time and generation. It's very important, I'll explain that below. Then we can make all required changes, fixes, compile the code and test it. Finally we can release this build with corrections.

And at the very last step we should have a way to start Vault client again and compare the files downloaded on the requested date with the original files on the SG keeping in mind that their dates can be renewed but the content can still be same (binary comparison, still doesn't exist but was nicely working in the Source-of-Site a ew years ago). Ideally we'll need to merge the fixes done to the code from the previous build with the latest code right on the server.

I realize that it's not easy but it can and has to be done. I'm sure all people will support me. It will save us same space on the server, a lot of hours branching the code after each release, and the most important thing - the efforts that we're using rolling back the source codes to fix something when we already went ahead after the release.

If you have any questions we could proably discuss this idea.

[Dmitri Shvetsov]

Na, only one man/woman, one vote here.

Linda, please don't make me ask the whole team to write here to count all their voices...)

Dmitri

[mlippert]

Dimitri,
I'm not sure what you're asking for, but it doesn't sound like rolling back a changeset which is what this thread was originally about.

Your quote from Dan doesn't seem to have originated in this thread.

BTW I'm pretty sure that Vault has a binary diff (well by CRC) for determining changed files, in version 3 and later at least.

Mike

[edit] oops, I see I missed the 1st page of this post where Dan's comment was.