Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      This is a followup on: http://www.lucidimagination.com/search/document/bb6c23b6e87c0b63/back_compat_folders_in_tags_when_i_svn_update#3000a2232c678031

      Currently we use tags for specifying the revision number in the backwards branch that matches the current development branch revision (in common-build.xml). The idea is to just specify the corresponding revision no of the backwards branch in common-build.xml and the backwards-test target automatically handles up/down/co:

      • We just give the rev number in common-build in common-build.xml as a property backwards-rev="XXXX". This property is used also in building the command line which is also a property backwards-svn-args="-r $backwards-rev". By that you can use "ant -Dbackwards-svn-args=''" to force test-backwards to checkout/update to head of branch (recommened for developers).
      • we should rename target to "test-backwards" and keep a "test-tag" with dependency to that for compatibility
      • The checkout on backwards creates a directory "backwards/$ {backwards-branch}" and uses "svn co ${backwards-svn-args} 'http://svn.../${backwards-branch}

        ' 'backwards/$

        {backwards-branch}

        '". The cool thing, the dir is checked out if non existent, but if the checkout already exists, svn co implicitely does an svn up to the given revision (it will also downgrade and merge if newer). So the test-backwards target always updates the checkout to the correct revision. I had not tried with local changes, but this should simply merge as an svn up.

      The workflow for committing fixes to bw would be:

      • First use "svn up" to upgrade the backwards working copy to HEAD.
      • Commit the changes
      • Copy and paste the message "Committed revision XXXX" to common-build.xml
      • Commit the changes in trunk
      1. LUCENE-2193.patch
        9 kB
        Uwe Schindler
      2. LUCENE-2193.patch
        10 kB
        Uwe Schindler
      3. LUCENE-2193.patch
        10 kB
        Uwe Schindler

        Activity

        Hide
        Uwe Schindler added a comment -

        Committed revision: 899001

        Show
        Uwe Schindler added a comment - Committed revision: 899001
        Hide
        Uwe Schindler added a comment -

        One small optimization to have only one update if the checkout is available.

        Show
        Uwe Schindler added a comment - One small optimization to have only one update if the checkout is available.
        Hide
        Uwe Schindler added a comment -

        Optimized version of the patch:

        • The backwards checkout is now sparse with the correct branch root folder, so patches in backwards branch look correct
        • added failonerror="true", so build stops when svn update fails. It does not stop on svn.exe not found, so this is secure!

        I'll commit soon and merge flex.

        Show
        Uwe Schindler added a comment - Optimized version of the patch: The backwards checkout is now sparse with the correct branch root folder, so patches in backwards branch look correct added failonerror="true", so build stops when svn update fails. It does not stop on svn.exe not found, so this is secure! I'll commit soon and merge flex.
        Hide
        Uwe Schindler added a comment -

        Two opinions:

        • the top-level "/backwards/" folder could be removed and the branch directly checked out into the top-level dir, as the branch name cleary says that it is a backwards-test branch. The svn:ignore in top-level folder then would simple be "lucene*_back_compat_tests" and the $ {backwards}

          references in the patch removed.

        • it is a little bit unhandy to use that the backwards-branch folder only consists of src/. To commit you have to go into src. Also applying/creating patches is harder with e.g. TortoiseSVN, because the patches are always relative to the top-level, which is "src" in this case. I suggest to checkout in two steps: First a non-recursive empty top-level folder and then the src folder inserted with an update command using the same strategy like "sparse checkouts" work (see svn book).

        I will think about it this night and maybe provide modified patches,

        Show
        Uwe Schindler added a comment - Two opinions: the top-level "/backwards/" folder could be removed and the branch directly checked out into the top-level dir, as the branch name cleary says that it is a backwards-test branch. The svn:ignore in top-level folder then would simple be "lucene*_back_compat_tests" and the $ {backwards} references in the patch removed. it is a little bit unhandy to use that the backwards-branch folder only consists of src/. To commit you have to go into src. Also applying/creating patches is harder with e.g. TortoiseSVN, because the patches are always relative to the top-level, which is "src" in this case. I suggest to checkout in two steps: First a non-recursive empty top-level folder and then the src folder inserted with an update command using the same strategy like "sparse checkouts" work (see svn book). I will think about it this night and maybe provide modified patches,
        Hide
        Uwe Schindler added a comment - - edited

        Here a patch that implements the above. It contains a lot variable renamings and some backwards-target (deprecated). Maybe we remove them before commit.

        To test:

        • Apply patch
        • remove tags/ folder (unused now). If you have modifications in it, create a patch
        • run "ant test-backwards"

        To modify backwards branch:

        • run "svn up" in backwards folder
        • modify backwards branch
        • to now test this modified trunk revision in checkout folder, you can pass "ant test-backwards -Dbackwards.rev=HEAD", but if you have done "svn up" as first step this is not needed
        • commit changes in backwards branch with "svn commit" (be sure to change to backwards/$branchname$/src, as src is the root folder of the checkout)
        • copy the revision number from commit message and insert into common-build.xml
        • (test again and) commit trunk

        Please test this and tell me if you like it!

        Show
        Uwe Schindler added a comment - - edited Here a patch that implements the above. It contains a lot variable renamings and some backwards-target (deprecated). Maybe we remove them before commit. To test: Apply patch remove tags/ folder (unused now). If you have modifications in it, create a patch run "ant test-backwards" To modify backwards branch: run "svn up" in backwards folder modify backwards branch to now test this modified trunk revision in checkout folder, you can pass "ant test-backwards -Dbackwards.rev=HEAD", but if you have done "svn up" as first step this is not needed commit changes in backwards branch with "svn commit" (be sure to change to backwards/$branchname$/src, as src is the root folder of the checkout) copy the revision number from commit message and insert into common-build.xml (test again and) commit trunk Please test this and tell me if you like it!
        Hide
        Michael McCandless added a comment -

        This sounds great! Basically, rather than explicitly naming the tag, we can use svn's revision instead. An "anonymous" tag.

        So it should also be fully safe, ie, there's no time when you could do a checkout and find the back compat tests are failing.

        Show
        Michael McCandless added a comment - This sounds great! Basically, rather than explicitly naming the tag, we can use svn's revision instead. An "anonymous" tag. So it should also be fully safe, ie, there's no time when you could do a checkout and find the back compat tests are failing.

          People

          • Assignee:
            Uwe Schindler
            Reporter:
            Uwe Schindler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development