Page MenuHomePhabricator

Base revision mismatch triggered by changes in SVN externals
Open, Needs TriagePublic

Description

When creating a diff with Arcanist in an SVN repository which contains modifications to both current-level repository files and external repository files a usage exception is thrown for mismatched base revisions. Reverting the files avoids the exception.

Here is a cleansed and snipped log.

$ arc diff
You have untracked files in this working copy.

  Working copy: /myPjt/

  Untracked files in working copy:
    .cproject
    .project
    .settings

Since you don't have 'svn:ignore' rules for these files, you may have
forgotten to 'svn add' them.


    Do you want to add these files to the commit? [y/N]



    You have not specified any reviewers. Continue anyway? [y/N] y

Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
The working copy includes changes to 'svn:externals' paths. These changes will not be included in the diff because SVN can not commit 'svn:externals' changes alongside normal changes.

Modified 'svn:externals' files:

        libs/canopen/pjt/engine/engine.mk
        libs/canopen/pjt/engine/genqmake.mk

    Generate a diff (with just local changes) anyway? [y/N] y

Usage Exception: Base revisions of changed paths are mismatched. Update all paths to the same base revision before creating a diff:

    Revision 203, .
    Revision 203, inc/App_Task.h
    Revision 154, libs/canopen/pjt/engine/engine.mk
    Revision 154, libs/canopen/pjt/engine/genqmake.mk

$ svn propget svn:externals .
^/../db_svn_bios/trunk/canopen_library@260 libs/canopen

Event Timeline

altendky raised the priority of this task from to Needs Triage.
altendky updated the task description. (Show Details)
altendky added a project: Arcanist.
altendky added a subscriber: altendky.

@altendky , does doing svn up help? I saw this error a few times, when I've commited a sub-folder, but haven't done svn up afterwards to line up revisions of each top level folders in the working copy.

Sorry @aik099, I guess I totally missed your question last year. In the example, the main repository is correctly listed at revision 203 and the external repository is listed at revision 154. They are separate repositories so it would only be by chance if they ever should be the same number. I will also mention that engine is actually an external of canopen which is an external of the main repository so my propget command isn't particularly relevant.

I would test this again but my arc is SEGFAULTing right now... :[

@altendky, when doing svn up the revision for each file in working copy is set to last commit in the repository in general, not last commit when each particular path was changed. This solved problem for me at least when using Subversion 1.6 client.

Were you using externals? This is specifically about externals which can not be expected to have the same base revision since they are an entirely different repository.

Yes, I'm using svn:externals from same repository. I have several base modules stored in repository and projects include these base modules via externals.

I'm not sure if it's possible to have svn:externals that point to different SVN repositories (not start with ^/ as in my case), but if that's where the case, then yes this would end up in a problem you're describing.

Yes, it is possible and that is what I am doing. :] You can point to an entire different server if you want, but we happen to have ^/../other_repo since the externals are on the same server.