How to handle project out of sync

Ulrich Eckhardt (236●1●22●23) | asked Nov 21 '11, 11:31 a.m.

I tried to discard a changeset and that involved deleting a folder, but RTC failed to delete that folder (This is on MS Windows and I think I had a shell open in that folder or maybe it was the virus scanner). Anyhow, now my component is marked as "out of sync" in the "Pending Changes" view and the folder shows up under the "Unresolved" changes. I honestly don't understand why RTC thinks it was out of sync, it seems perfectly in sync to me.

Now, when I try to "Undo" the folder from the "Pending Changes", RTC tells me "Local projects are out of sync with your repository workspace. ...". What projects is it talking about? I'm not using those Eclipse ".project" files but doing all editing externally, in case those are meant. Or is it just another case of confused terminology?

Secondly, how do I get back in sync? RTC suggests reloading as an option, but that would firstly nuke all my local changes and secondly it would also touch all files, so I would be in for another 50-minutes compiler run. So I guess suggested alternative "disconnect and reshare" would be the way to go, but that is an option I can't find anywhere!?

Any suggestions what to do? I can use a different workspace for now, but ideally I would like to avoid such cases and resolve them gracefully in the future...

Uli

Comments

Shimon Nir commented Feb 13 '13, 11:44 a.m. | edited Feb 13 '13, 11:52 a.m.

How many files are we talking in this situation ? I have a similar situation with 1 component and ~40000 files. This is because all files are somehow connected and it was very difficult to split the component to several physical components that make logic. Having this situation, reload takes about 90 !!! minutes ? What can be done to decrease the time ?

Tim Mok commented Feb 13 '13, 11:54 a.m.

JAZZ DEVELOPER

The reload is incremental and only affects out-of-sync projects. I think it's better to figure out why you are becoming out-of-sync so that you can avoid it. For loading/reloading taking a long time, that would be an issue of scalability and isn't related to the poster's question.

7 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Geoffrey Clemm (30.1k●3●30●35) | answered Nov 21 '11, 5:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Yes, this error message should be improved. It should say something like:
"Files in your sandbox are out of sync with your repository workspace".
I've submitted work item 185778 to get this fixed.

What matters is whether the metadata associated with the sandbox is
synchronized with the metadata about the workspace in the repository.
(The fact that it seems in sync to you is not sufficient :-).

And the right answer is to re-load, with the "reload projects out of
sync" action. In my experience, this will never overwrite any of your
local changes, and it definitely will not change the date stamp on any
file that is currently loaded and in-sync with what is in the repository.

But until we get confirmation from the RTC SCM team that the "re-load
out of synch" operation will never overwrite local changes, I'd store a
copy of your sandbox in some temp directory before doing the load, just
in case.

Cheers,
Geoff

On 11/21/2011 11:38 AM, ulricheckhardt wrote:

I tried to discard a changeset and that involved deleting a folder,
but RTC failed to delete that folder (This is on MS Windows and I
think I had a shell open in that folder or maybe it was the virus
scanner). Anyhow, now my component is marked as "out of
sync" in the "Pending Changes" view and the folder
shows up under the "Unresolved" changes. I honestly don't
understand why RTC thinks it was out of sync, it seems perfectly in
sync to me.

Now, when I try to "Undo" the folder from the "Pending
Changes", RTC tells me "Local projects are out of sync with
your repository workspace. ...". What projects is it talking
about? I'm not using those Eclipse ".project" files but
doing all editing externally, in case those are meant. Or is it just
another case of confused terminology?

Secondly, how do I get back in sync? RTC suggests reloading as an
option, but that would firstly nuke all my local changes and secondly
it would also touch all files, so I would be in for another 50-minutes
compiler run. So I guess suggested alternative "disconnect and
reshare" would be the way to go, but that is an option I can't
find anywhere!?

Any suggestions what to do? I can use a different workspace for now,
but ideally I would like to avoid such cases and resolve them
gracefully in the future...

Uli

permanent link

Ulrich Eckhardt (236●1●22●23) | answered Nov 22 '11, 3:16 a.m.

What matters is whether the metadata associated with the sandbox is
synchronized with the metadata about the workspace in the repository.
(The fact that it seems in sync to you is not sufficient :-).

And the right answer is to re-load, with the "reload projects out of
sync" action. In my experience, this will never overwrite any of your
local changes, and it definitely will not change the date stamp on any
file that is currently loaded and in-sync with what is in the repository.

When I click "reload these projects" from the "Pending Changes" view, I get a multiple-choice dialog with the default saying "Reload projects that are out of sync.Local changes will be overwritten" (emphasis mine). So at least the Eclipse UI assumes that the changes will be lost.

Also, here's yet another place where Eclipse and RTC terminology collide, assuming this is actually talking about RTC components and not RTC projects. BTW: Is there a work item associated with this? I have come across the problem of inconsistencies in naming quite a few times since adopting RTC and it's a PITA, albeit a small one. Latest example I noticed is on startup where RTC informs me "Rational Team Concert stores your projects in a folder called a workspace." (emphasis mine) and then asks me to select a workspace.

But until we get confirmation from the RTC SCM team that the "re-load
out of synch" operation will never overwrite local changes, I'd store a
copy of your sandbox in some temp directory before doing the load, just
in case.

I'll try reloading and report back here whether the changes were preserved. I'll take the mentioned link in the "Pending Changes" view and simply ignore that it claims to undo all local changes.

Uli

permanent link

Ulrich Eckhardt (236●1●22●23) | answered Nov 22 '11, 3:53 a.m.

For the record, reloading deleted the directory it initially failed to delete but also deleted other changes in the sandbox. However, it also preserved some changes there. I can't give an exact rule which change was preserved and which change wasn't. It could be that the preserved changes had an entry in jazzignore files in common.

Uli

permanent link

Geoffrey Clemm (30.1k●3●30●35) | answered Nov 22 '11, 11:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note: If you copy the directory tree that you saved on top of the
current content, you'll see all of the differences in the "Unresolved
Folder". You can scan through that to see if there are any changes you
want to keep ...

Cheers,
Geoff

On 11/22/2011 3:53 AM, ulricheckhardt wrote:

For the record, reloading deleted the directory it initially failed to
delete but also deleted other changes in the sandbox. However, it
preserved some changes there. I can't give an exact rule which change
was preserved and which change wasn't. It could be that the preserved
changes had an entry in jazzignore files in common.

Uli

permanent link

Geoffrey Clemm (30.1k●3●30●35) | answered Nov 22 '11, 5:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Please do report any terminology problems of this kind that you find.
Reporting them separately as you encounter them, or in a batch, whatever
you find easier.

In general, with the potential confusion between Eclipse projects and
RTC project areas, the less RTC messages refer to "projects", the better
(:-).

Cheers,
Geoff

On 11/22/2011 3:23 AM, ulricheckhardt wrote:

When I click "reload these projects" from the "Pending
Changes" view, I get a multiple-choice dialog with the default
saying "Reload projects that are out of sync.Local
changes will be overwritten" (emphasis mine). So
at least the Eclipse UI assumes that the changes will be lost.

Also, here's yet another place where Eclipse and RTC terminology
collide, assuming this is actually talking about RTC components and
not RTC projects. BTW: Is there a work item associated with this? I
have come across the problem of inconsistencies in naming quite a few
times since adopting RTC and it's a PITA, albeit a small one. Latest
example I noticed is on startup where RTC informs me "Rational
Team Concert stores your projects in a
folder called a workspace."
(emphasis mine) and then asks me to select a workspace.

permanent link

Tim Mok (6.6k●3●8) | answered Nov 23 '11, 12:08 p.m.
JAZZ DEVELOPER

In the future, I would suggest checking in any unresolved changes before altering your repository workspace. Then if your sandbox becomes out of sync, you can reload without worry about losing any work.

The reload should be reloading out of sync files only. If the unresolved changes are out of sync, they'll be lost. It would be safest to create a patch for the unresolved changes so that they can be applied if any of them are lost as a result of the reload. Or make a copy of your sandbox as Geoff suggested.

Comments

Jens Melgaard commented Feb 12 '13, 9:37 a.m.

Considering that you can't check in unresolved changes when you become out of sync then that only goes so far. And it's not always you realize that your doing something that would cause the work-space to go out of sync.

Besides the RTC client of e.g. Visual Studio does a poor job of discovering changes. This can even include changes made from inside Visual Studio (here we talk Solution level changes).

Many of the other SCM I have worked with let changes pop up ones you begin to edit an file, then warn before checking in if you have not saved that file.

All that said... the RTC Sandbox vs Workspace concept would be much better if Commits and Updates between those two would be treated just as a Commit or Update between a Workspace and a Stream...

That would Kill of the ugly "out-of-sync" concept and replace it with a more simple "workspace have incoming changes for your sandbox"... which when updating/accepting those would give you the opportunity to merge those files rather than overwriting them.

Tim Mok commented Feb 12 '13, 10:02 a.m.

JAZZ DEVELOPER

I mentioned checking in files before doing anything with the repository workspace such as accepting or delivering changes. I consider this a best practice to ensure work is now versioned on the server and will be safe from any disasters (eg. harddrive is corrupted).

A repository workspace goes out-of-sync when the repository workspace is altered with a different client than the one used to load the content. This can easily be avoided by using one repository workspace per sandbox. I think the issue in this question was opened as a defect. It doesn't sound right to be out-of-sync when the change set discard failed due to some external process having a hold on the folder.

For VS, the filesystem listening has been improved with each version but you may want to file a defect if it's not detecting changes properly. The VS and Eclipse clients also have an auto-checkin option as well as the "check-in and deliver" action if that suits you.

Jens Melgaard commented Feb 13 '13, 5:58 a.m.

Clearly I didn't elaborate enough then.

I develop using a number of virtual machines, that means that I do in fact have several sandboxes attached towards the same work-space anything else would mean I would have to do an insane insanely "complete, change flow target, accept, change flow target back, commit" cycle.. So i desire 1 Work-space pr. Project pr. User.

This causes a lot of out-of-sync situations... and because of the character limit I can't really elaborate on all of those here...

As for the "file system watcher"... we are on 4.0.1(I4.0.1_20121112-1122), i can't say if the issues around changes to solutions still is an issue, but I can for sure say that changes made outside Visual Studio does not get discovered (as they would in AnkhSVN or the Git plugin for VS)... And we do manage files in other tools, like rake build scripts, images, help files and much more...

But I mean, you have this "backup shed" feature, and no offence, that's a symptom.

Tim Mok commented Feb 13 '13, 9:19 a.m.

JAZZ DEVELOPER

Your requirement to load a repository workspace to multiple sandboxes isn't recommended because you'll encounter out-of-sync situations. This is working as designed and a limitation of the design. Your situation will easily cause out-of-sync problems because you're altering the repository workspace and your RTC client cannot update or possibly know about all the sandboxes where it has been loaded.

If you need to load the same content twice, you'll be better of using one repository workspace per sandbox. If you need to work on a change in one sandbox and get it to another sandbox, you can suspend the change set and resume it in the other.

There is an option in VS to automatically detect changes outside of the VS environment. I'm unsure of the reason it is disabled by default but you can open a defect if you feel it should be enabled by default. There may be a reason for this but someone from the VS team will have a better idea.

VS also has a refresh in Pending Changes. There's a drop-down on the refresh button to explicitly check for new content instead of relying on filesystem listening. The refresh will likely take longer though.

Jens Melgaard commented Feb 13 '13, 10:23 a.m.

And what I am trying to say is that it is badly designed in my opinion then. Why would it be so difficult to "merge/conflict" files? Rather than just blindly overwriting them?

The suspending approach was also unknown to me, but it also has disadvantages, so now I am now up to 3 different approaches all causing deficiencies. I still prefer to deal with out-of-sync issues as provides the simplest workflow as long as I remember to sync before starting to work...

But I will still stand by my opinion that the "backup shed" and "out-of-sync" aren't features, but symptoms of defects or bad design.
https://jazz.net/library/article/191/

And yes I know there is a "refresh" local and remote changes in Visual Studio and I have come to a point where I always click it prior to check-in, if i remember it, simply because I flat down don't trust RTC. (that's also a symptom)

Jens Melgaard commented Feb 13 '13, 10:23 a.m.

The biggest problem is that my trust in RTC has only declined over 2 year or so of use.

Tim Mok commented Feb 13 '13, 11:32 a.m.

JAZZ DEVELOPER

Updating sandboxes due to a repository workspace change isn't as simple as merging any changed content. There may be local changes when the repository workspace was modified elsewhere. The client managing that sandbox may not be running. It could be a variety of reasons why modifying a workspace cannot update the sandboxes where it has been loaded. This will be what happens when repository workspaces are loaded into multiple sandboxes.

What kind of deficiencies do you find with these alternate solutions to loading the same content in multiple sandboxes? Perhaps you can open a work item explaining your use case.

Have you tried the VS option to monitor changes external to the client?

Jens Melgaard commented Feb 14 '13, 2:21 a.m. | edited Feb 14 '13, 2:34 a.m.

You misunderstood completely... (and it's not that difficult as any other SCM vendor I know of does this)... Your problem is properly that you don't see the workspace and sandbox as their own separate version of the truth, instead you wan't them to share the same truth.

Instead try to embrace the ideology that the sandbox is a branch of the workspace for a second. This should eliminate all out-of-sync issues.

If we take it a level up, Workspace (W), Stream (S). When W1 has changed a.txt and delivers that to S, W2 gets that as an incoming change, so when he pulls that and also has changes to a.txt it will try to merge, if it can't it will put the files in conflict to the user to solve. Now replace Workspace with Sandbox and Stream with Workspace. Woala.

Jens Melgaard commented Feb 14 '13, 2:26 a.m.

Now as I see it you don't need to change the entire infrastructure... instead you can just during "reload out of sync" say "Hey file a.txt on the workspace is different than file a.txt in the sandbox let me ask the user what I should do about this by giving him a conflict to resolve".

This would have no dependency to what local changes is in another sandbox. That sandbox might just get conflicts as well when it is re-synced... I can't see how that approach is so difficult... And IMO it's the only right thing to do... It would also eliminate the need for "I can see you have local changes, would you like to check those in before accepting incoming changes, if you don't they will be overwritten"... because again, local changes would also result in conflicts...

Jens Melgaard commented Feb 14 '13, 2:34 a.m.

The deficiencies about the other 2 approaches is the heavy workflow around it which would take up quite some time, especially if you where to forget to follow that very strictly laid out workflow.

E.g. in the suspend case, I could work in the office, forget to "suspend" (which in it self is an action which takes time)... then leave with the train, log on and wanting those changes on the road, but now I can't because I forgot to suspend them... Then I have to log in remotely, suspend the changes, log out, resume... And the next day I leave my laptop at home and I again forgot to suspend the changes, but no worries I can just load that workspace at work, suspend it there (which I am no longer sure why I would)... Resume it at the actual "work sandbox"... remember to remove the "temp for suspend" sandbox (because we don't wan't that to cause out-of-sync errors)...

But so what I hate in the above is the huge overhead in tasks this can generate...

Jens Melgaard commented Feb 14 '13, 2:39 a.m. | edited Feb 14 '13, 2:55 a.m.

And yes the option in VS helps in some of the cases, there is still cases that at least AnkhSVN handles better, one is when I add a file to a project, RTC won't discover the change to the project (as it is not saved yet)... also starting to editing a file is not discovered either. This is things that gets picked up by AnkhSVN at least, I haven't tested it with the Git Provider.

In any case, this discussion is getting long and boring...

But Consider looking at sandboxes like small branches (or streams if you will) of the Workspace, It would solve so many problems IMO.

showing 5 of 11 show 6 more comments

permanent link

Christophe Cornu (471●2●3) | answered Feb 14 '13, 1:31 p.m.

>" I develop using a number of virtual machines, that means that I do in fact have several sandboxes attached towards the same work-space anything else would mean I would have to do an insane insanely "complete, change flow target, accept, change flow target back, commit" cycle.. So i desire 1 Work-space pr. Project pr. User.
This causes a lot of out-of-sync situations... and because of the character limit I can't really elaborate on all of those here..."

Hi Jens: please open an enhancement request with your use case. You're correct to say that RTC SCM's preferred workflow is to check-in frequently against your private workspace, and accept/deliver between different repo workspaces or streams rather than having the same repo workspace used in multiple clients simultaneously. This approach provides the full SCM traceability (file history, even of intermediate check-ins through the file history's view check-in history pane, a feature introduced in 4.0), early awareness of team conflicts - when you edit and check-in a file and someone else delivered a change to that same file, etc. If you keep working the way you're setup, you're hitting a path the tool can recover from, but I would not work that way every day. One reason I would not work the way you described is that by reusing the same active change set or repo workspace on multiple VMs and sandboxes, you are also losing the traceability of where a change comes from. Doing changes on a client in a particular change set makes it easier to backtrack these changes atomically instead of looking at 10 changes from 3 different VM's done at different times. There are certain benefits to check-in and use different change sets for changes that make sense together.

If you want improvements to the change flow target / accept / deliver workflow, maybe you want to add yourself to "160738: support directed flows throughout Jazz Source Control". We make it easy to switch between flow targets or even scope a flow target to a particular component (change flow target on a particular component in your workspace in the pending changes view). But we could consider even more interesting scenarios with multiple ones and specify the way they flow. You can describe how you work with multiple VM's and sandboxes, i"d be interested to hear more on that plan item or your enhancement how you need to do multiple edit's and checkins from different VM's and clients to resolve the pbs you are working on.

HTH, thanks!

Christophe

Comments

Jens Melgaard commented Feb 15 '13, 4:08 a.m.

We view change-sets differently, it's not important what machine or workstation they come from, why would that ever be important? Its important who delivered (as in the person), and what he delivered, what he stated about the delivered (comments, which is also implemented horribly as an input on a tree node, not to mention the bugs around it), and then what work-items (again horribly implemented, or used to be at least, you could only ever search for the exact ID to find what you needed in that dialog).

I start a task on my workstation, continue that task on my laptop else where. or I switch to a VM to run tests on different environments to ensure that the change-set won't break anything, if they fail in a particular environment I often fix it there.

Jens Melgaard commented Feb 15 '13, 4:11 a.m.

Besides, if you can track commits, then you still get that history because obviously 2 machines can't make a single commit, that would have to be 2 commits, so I can't see why that would change anything in the history, and if the machine is important, you need to do something extra anyways.

I have switched my main workstation and had 2 different laptops in the time I have worked on the same project with RTC... Why wouldn't i just reuse the Workspace when i replaced a PC... (The old sandbox would never get used in that case)... Also I have had a number of re-installs due to upgrades to SSD's and finally I wen't into using quite a bit of VM's as I ended up working on multiple projects, extended that as some of those demanded extra platform support.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

It's all about the answers!

Related questions

How to handle project out of sync

7 answers

Your answer