#554: GetComponents deletes local changes ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- After checking out an svn repository with GetComponents, I manually switched to a different branch, and added local changes. GetComponents --update then checked out the original branch and deleted all my local changes.
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by knarf):
* owner: eschnett => eric9 * priority: blocker => minor * component: SimFactory => GetComponents * milestone: => ET_2011_11
Comment:
I can reproduce the branch-change. I know why it happens (meaning I know the code), but I don't know why this was done. Is there a reason we should call 'svn switch' (without --relocate) if the URL of the repo doesn't match up with the actual checkout? If we change that our options are either a) abort, since we cannot update using the given thornlist because there is another checkout 'in the way', or b) simply update, ignoring the URL specified in the thornlist.
Any way - I cannot get local changes being overwritten, the worst I could produce are conflicts, but the changes are still there. Thus, I am lowering the priority. Please change again if you can reproduce the data loss (and let me know how to).
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by knarf):
* status: new => review
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by anonymous):
The problem arose when I had the Python Simfactory checked out, and GetComponents switched back to the Perl Simfactory. The conflicts that I expected had to do with additional files I had in the directory structure. I now see that these files are preserved over GetComponents branch switch, but the files are afterwards in an unexpected location in the directory structure. Also, GetComponents can not switch back to the Python version because the directories containing these new files then count as conflict.
So, apparently no files were lost, I just couldn't find them any more.
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by knarf):
Ok, good. That leaves as open question whether GetComponents should do the switch in the first place. There are arguments for and against it. For doing the switch could speak that you ask GetComponents to update given thornlist, which might indicate that you actually want to update using the URLs in that thornlist. Of course, against it speaks that since the checkout points to actually different code (within the same repository), this is likely to be intentionally and all you want is to update that, and not to move to a different branch.
GetComponents cannot know what you actually want. It was asked to update a repository with URL A, but instead finds one with URL B. The best solution in that case might actually be to not do anything to the repository, and reporting this as error. Note that this would be different from the relocating switches, which would still happen.
Opinions?
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by anonymous):
I would prefer aborting.
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by hinder):
I think !GetComponents should update the currently checked-out branch in this case, and also give a warning (in a prominent position, i.e. at the end) that the currently checked-out branch was different to the branch in the CRL file. Users who wanted this to happen will then be happy, and I think this will be the most common case. Users who wanted to switch branch back to what was in the CRL file can now do so, with no harm done.
#554: GetComponents deletes local changes ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by hinder):
* milestone: ET_2011_10 =>
Comment:
This doesn't lead to the deletion of user data so is marked as "minor". I think it will only affect people who know enough to understand and fix it. Since we are getting close to the release, I propose that we defer handling this in the best way until after the release. Frank's patch tells the user to fix their conflicts in the case that some are generated. Since this should be fairly harmless, assuming the patch works, it could be committed. In any case, I am removing the release milestone - feel free to add it back if you feel it should be fixed before then. Note that this problem has likely always been there. Note also that we are no longer using a separate branch for simfactory.
#554: GetComponents switches branches the user has checked out ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: review Priority: minor | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
#554: GetComponents switches branches the user has checked out ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: closed Priority: minor | Milestone: Component: GetComponents | Version: Resolution: fixed | Keywords: ----------------------------+----------------------------------------------- Changes (by knarf):
* status: review => closed * resolution: => fixed
trac@lists.einsteintoolkit.org
-
Einstein Toolkit