0

We have a standard layout with

tags
branches
trunk

But no code is present in trunk. Trunk has never been used. Instead all work has been done in a branch and once that branch has been considered done a new branch has been created. From now on all releasable code will reside in trunk since that is how every other project we have is set up and that is how we have TeamCity fetch and build all the latest releasable projects when building an install package.

Under branches there exist a 1.0 branch and a foo branch that is branched from the 1.0 branch.

branches
 |- 1.0
     |- foo

foo is currently being developed on and 1.0 contains the latest released code. My idea was to merge 1.0 with trunk and then, when foo is done, merge that with trunk. Would that pose any issues since it's based on 1.0, which trunk will also be, and trunk might contain other changes not present in foo?

Also, at what point would it be considered safe to delete the 1.0 branch? Straight after 1.0 has been merged to trunk or after foo has also been merged?

inquam
  • 12,664
  • 15
  • 61
  • 101

1 Answers1

0

  1. You have to fix your workflow and mind - they are broken

    • If you created trunk's HEAD from some ancestor of foo, trunk can't contain (later) changes, which doesn't exist in foo (if all development happens in foo).
    • You try to use 1.0/foo as trunk and trunk as tag

  2. You can delete svn rm obsoleted branch (1.0) only when foo will be also obsoleted - Subversion repository is path-based - you can't remove 1.0 but leave foo intact

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • So the easiest way would be to *rename* branches/1.0 to trunk? All other projects adopt the *no junk in the trunk* way of working which makes it easy to setup for automatic building on the build server and making sure all the latest accepted code is used. This is the only legacy project that differs and brakes everything :) – inquam Jan 30 '13 at 13:03
  • Regarding #2: Ok, thought you might have been able to re-base foo somehow. – inquam Jan 30 '13 at 13:06
  • @inquam - I think: easiest - "yes", but most correct - `svn cp` 1.0 tree (files and subdirs, not related with foo) into tunk - maybe in a sequence of single-file copies, but with saved history – Lazy Badger Jan 30 '13 at 13:07
  • And then merge foo with 1.0 and then 1.0 with trunk? – inquam Jan 30 '13 at 13:17
  • @inquam - you can directly merge foo into any code, which have with foo common ancestor, merge+merge merged (when **final target is equal to immediate* before foo merge) haven't a lot of sense and +1 operation - trunk in your case is a clone of 1.0, all changes of trunk and foo are changes between parent revision of trunk (from 1.0) and HEAD of foo (which is descendant of 1.0 and, thus - of trunk's parent also) – Lazy Badger Jan 30 '13 at 13:25