CodingGorilla Posted April 30, 2012 Report Share Posted April 30, 2012 I often cloak the app.config files on my development machines, because the file is slightly different between machines (usually db connection strings). But whenever I try to do a check-in, plastic detects the file as being changed and includes it in the check-in list, but then throws an error indicating "There are no changes in the active workspace [workspace path]". Is this the expected behavior? Link to comment Share on other sites More sharing options...
carpediemevive Posted April 30, 2012 Report Share Posted April 30, 2012 I've had this happen to myself and a couple of other developers but hadn't found a solution besides avoiding cloaking files altogether. Any advice on this would absolutely be helpful. Link to comment Share on other sites More sharing options...
manu Posted May 2, 2012 Report Share Posted May 2, 2012 Hi! you are both right! The checking operation doesn't take into account the cloaked files so if the cloaked file is the only one that it's changed in the workspace the internal changed list will be empty and you get the "no changes in workspace...." message. We can think in a better solution together, I have just return from a hardcore music festival in Belgium and I'm not 100% operative Link to comment Share on other sites More sharing options...
carpediemevive Posted May 2, 2012 Report Share Posted May 2, 2012 So if I understand clearly, what Plastic is concerned with is that the cloaked file has changed, and if we switch branches or anything those changes would be reverted. Is that why Plastic is tracking it as "changed" in the first place? My own internal thinking is that cloaked files and ignored files are basically the exact same thing, with the exception that an initial version of the cloaked file is kept in version control and is created when downloaded/updated into a workspace. Given that thinking, on check-in, the presence of a changed cloaked file should be treated just like a changed ignore file, and completely ignore by the check-in process. If, on branch switch (or switching to a label, changeset, or any other changes to the selector I guess) there are cloaked files that are changed and you want to ask the user whether they want to keep their changed cloaked file, or download the original again, that could work. Link to comment Share on other sites More sharing options...
manu Posted May 2, 2012 Report Share Posted May 2, 2012 Given that thinking, on check-in, the presence of a changed cloaked file should be treated just like a changed ignore file, and completely ignore by the check-in process. If, on branch switch (or switching to a label, changeset, or any other changes to the selector I guess) there are cloaked files that are changed and you want to ask the user whether they want to keep their changed cloaked file, or download the original again, that could work. I think this one is perfect. You can now add it to the hidden changes list (right click on the item) and the checkin and update operation will not complain about it. But If you really want to commit the cloaked file I think we need something better than uncloaking it and try to commit it without be hitting with the "outdated items message" since you can be working with an invalid revision. Link to comment Share on other sites More sharing options...
carpediemevive Posted May 2, 2012 Report Share Posted May 2, 2012 Ahh, alright, that works. Thanks Manu! Yea, the second point would be a problem. Thankfully for me it doesn't happen all that often, so that level of pain is probably OK. Link to comment Share on other sites More sharing options...
CodingGorilla Posted May 2, 2012 Author Report Share Posted May 2, 2012 OK, so just let me make sure I understand: Cloaking a file means that updates that are committed to the repository are not applied to my local version of the file; this let's me change my connection strings based on the computer that I'm working at. Adding it the the "Hidden Changes List" will mean that I can make changes to my locally cloaked file and plastic will essentially just ignore it all together, but still maintain a repository version of the file (it has to be in the repository so it will compile properly). Am I understanding that properly? Link to comment Share on other sites More sharing options...
manu Posted May 3, 2012 Report Share Posted May 3, 2012 Yes, completely right. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.