Looks like this is an old request, but I DO want this to be able to undo a lock in Gluon on a file without losing my changes. For my needs I don't need the timestamp to not change, so there is a workaround of copying the file in the file system, undoing, then copying the backup back, but that's a hassle.

At this point cloaked are not applied to the initial update (which is definitely something that could help in other cases).

You can add cloaked.conf to your repo, so everyone shares the same configuration.

I will double check again to see if we can find another solution.

- Isn't cloaking applied to initial update as well? That is, the file is not being downloaded from the server, hence the application won't compile. Furthermore, what will need to be added to that list? Every developer might have different files changed locally, adjusting different components. There is simply no way to specify that kind of list.

- The files we're talking about are possibly *very* basic header files. That is, every single projects needs a recompile. In contrast, jumping through branches (bugfixing, etc.) affects only a small subset of the code.

- Shelves will solve the problem of keeping the modifications instead of rewriting them each and every time. They will not solve the rebuild problem though. Visual Studio will recognize the file being modified because the timestamp has changed.

The problem is that we have quite a big software which has a long compilation duration. Hence we need a way to switch branches without that basic files being modified.

Ok, then there are several options:

* You can cloak the files, so the update won't warn you about them, and won't update its contents when you switch branches.

* You're worried about changing the files and triggering a build, but it will happen anyway when you switch branches with *other* files, correct?

* Or, you can always use shelves for this. It takes an extra step, but maybe you can have a shelve with your personal log and debug configuration...

Those files aren't automatically generated. E.g. the logger configuration is checked in. Likewise, you enable some debugging code in an arbitrary cpp file in the solution. Then you want to switch branch and realize that there is a checked out file which isn't supposed to be checked in. That file shouldn't be altered, but it makes it impossible for you to switch branches. Currently, you are forced to undo checkout (loosing changes, maybe shelving first, applying shelve later. Anyhow, file is altered, build is necessary). The idea is to simply change status "checked out" to "changed".

Jan,

Shouldn't these files be outside the version control? I mean, if they are autogenerated and everyone keeps their own, just delete it from version control, don't you think so?

We're just trying to figure out the best solution.

pablo

Hi,
I'm not suggesting to modify the behavior of the current "undo checkout" command. I am seeking for additional functionality. I'm not sure yet about how to call it. Something like "remove checkout marker" :)
UseCase: We have some files that the user changes locally very often: Global header files which add some additional debug functionality to our product; logger configuration files; xml configuration files; ini files which are versioned but are altered by our tools. Modifying those files can result in massive rebuilds (30 minutes and more). We consider to put those files on the hidden_changes list.
Suppose some of these files have been checked out, for example by the Visual Studio plugin (since they are listed in projects and one would edit them in Visual Studio). Now, it is impossible to switch branches. Furthermore, the files aren't hidden anymore.
The developer simply does not want to check in those files. But he wants to preserve his modifications and does not want the timestamp of the file to be modified (avoiding rebuilds)...

Hi Jan,

Interesting, but this is a radical change in the behavior of undo checkout.

Question: what's your use case? You want to undo a lock or something? Otherwise I can't see why it is useful, I mean, why not leaving it checked out?