Home/ Questions/Q 9138669
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T09:17:13+00:00

I have old application version. It is provided me from external company in the

  • 0

I have old application version. It is provided me from external company in the past and it is basically live version of application.

While bug fixes are performed on this version, external company developed new functionality(significant model changes) on existing version. Now I have old application version(which is live) and last application version(not tested and needs some more changes).

Now I wanted to put all of that on svn and I have done the following steps:

  1. created repository in trunk folder and added new app version files there
  2. created repository in branches folder for old app version
  3. created tags for both repositories in tags folder.

In the next period, I should continue with development on last version(trunk) and in the same time fix bugs on old version(branch). How to (weekly) merge changes from my branch version to trunk? I tried with merge options, but results are really weird(content of some folder is totally removed), what do you think is the best solution for this situation, I do not want to manually change trunk code every time i fix bug on branch

Thanks,

Minja

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You made some mistakes on initial steps, and, as result, have two unrelated pieces of code, for which Subversion doesn’t know evolution path.

    Slightly modified workflow may be:

    For empty repository with default single-project layout (your current)

    • Import OLD-CODE into /trunk (or add files with checkout+add+commit)
    • Branch this trunk to some branch (svn copy URL-OF-TRUNK URL-OF-BRANCH-OLDCODE)
    • Get WC of trunk (svn co or use WC from step 1)
    • Replace OLD-CODE in WC by NEW-CODE
    • Commit trunk

    After it your subsequent merges will be (only slightly) less-headache tasks. Only slightly because merging far changed refactored code isn’t easy task in any case, but you’ll have at least continuous history for your code and common parents for diffing.

    Bad news: The need for a continuous history dictates the additional requirements for the operation of code-replacement in the penultimate step: you can’t just delete outdated files/directories and add new if new objects are descendants of old objects (childs of refactoring) – you have to support history between parent-child (svn mv instead of result of OS-replacement svn rm + svn add and unrelated files in logs). Worst news: I don’t know how to do it (find all candidates for svn mv) in bullet-proof way in reasonable time, using only Subversion

    • 0