GetComponents switches branches the user has checked out

Create issue
Issue #554 closed
Erik Schnetter created an issue

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.


Comments (10)

  1. Frank Löffler

    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).

  2. anonymous
    • removed comment

    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.

  3. Frank Löffler
    • removed comment

    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.


  4. Ian Hinder
    • removed comment

    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.

  5. Ian Hinder
    • removed milestone
    • removed 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.

  6. Log in to comment