Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Hardy on January 19, 2010, 06:41:36 am
-
I tried to check out a package from EA7.5 and got error message "the selected package cannot be checked-out at this time. The associated XMI package file is already checked-out."
My version control underneath is SVN, I checked everyewhere and nothing is checked out. I tried to get all latest version, and I still could not check-out, and have nothing to check in.
-
BTW, it happens to only one of my package, the rest of them are fine.
-
Try synchronizing the package statusses with the SVN status:
right click on package/Package Control/Re-synch all statusses with VC providers.
That should solve the issue.
Geert
-
Hello,
you are right this will help. But I want to point out that this function can be also very dangerous.
We use clear-case with the separate view for each user, in this configuration this function breaks all checkout of another people since it compares the state of XML files only with your view.
I have already reported this bug a few weeks ago and sparx accepted it... I hope they will fix it ASAP.
-
The synchronisation option is a bit of a nuclear option and has been mentioned in other posts, if you could be selective then it would be much more useful.
Where svn and ea go out of sync and in the absence of anything better I:-
1) Find out what ea thinks the status of the package is - query the ea t_package table
2) Get sub-version to agree by using subversion client to commit or check out.
Usually that does the trick.
If you still get problems I've been able to use tortoise repo browser to break the lock on the lock owners pc then get the lock again.
Hopefully something better will come along soon!
Neil
-
Further, you can right-click on the package in question and select Package Control...File Properties to see which user owns the lock. If a user really has checked out the package you can then have the user do a check-in or undo check-out. Sometimes, though, EA is confused about the state. (I'm pretty sure this happens if a user starts a check-in but hits cancel in the dialog.) In that case I agree the best bet is to break the lock through TortoiseSVN.