[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

avoiding tree conflicts in controlled website

From: Eric Horne <subversion_at_box11.org>
Date: Tue, 07 Dec 2010 07:29:19 -0800

Hello subversion users. I have a 'how-would-you-do-this' question for
you. An answer wasn't apparent on google or recent SVN mail archives, so
I'm hoping you kind folks can help.

Subversion is controlling change to a website I manage (running the CMS
Joomla!) , which is to say subversion holds the source of record for
what is supposed to be public. We have third party extensions installed
on the site as well. From time-to-time the extensions (and Joomla!
itself) are altered to our specifications. The desire is to use
subversion to track changes, and more importantly manage our localized
changes against incoming changes from the third-party extensions (and
updates from Joomla! )

What I have done is I've created a trunk for the base Joomla! release
and branched that trunk into a site specific branch. Similarly, I would
like to place the unbundled extensions into their own trunks in the same
repo and branch them when a local change is needed, and then merge that
branch into into the website's branch. For example, the website contains
a top-level 'components' directory. An extension adds stuff inside that
directory to make 'components/com_mystuff/...'.

Here's the rub: when I import the base extension code subversion wants
to create the 'components' directory as a new entity creating an 'evil
twin' (in ClearCase lingo). So when I go to merge the extension branch
into the website branch, I get a tree-conflict and no merge of the
directory. Note that extensions probably also go into more than just the
'components' directory (they could also go into
'administrator/components', 'plugins/content', 'languages', or any
number of other places).

A solution that seems to work is to branch the Joomla! base into the
extension branch first, then manually merge all the new directories (an
extension should NEVER change an existing file, it will always be new)
from the extension I want to add into the extension branch. Check in and
merge into the website branch. While it works, it seems very
heavy-handed (checking out 9000+ files/directories to add new structure
that affects a very small percentage of those checked out items).

Another solution is to first create the common directory structure and
import that first. Then add the new files, and merge from that revision
forward (skipping the initial import). While it also works, it will
break the first time a component update adds a new common directory and
I don't catch it first. Plus it still creates the evil twins, they are
just ignored; that seems less than robust.

Similar to the one above, I could branch the individual new directories,
but I think I still end up with the contents of those directories (e.g.
merging just 'components', I'd get 'components/com_notrelated1' and
'components/com_notrelated2', ... so less than all the files in Joomla!,
but still quite a few). This would also force me to individually branch
each common directory, which seems like a lot of tedious and error-prone
prework.

The final, and least attractive solution I thought of was to merge from
the new directory levels and below. This is really not something I want
to do because it requires remembering which directories are common and
which aren't, and it would require 4 or 5 merge attempts (one for each
new directory under a common directory). And if it starts adding files
into common directories, I'd have to merge each individual file. yikes!

Ideally, there would be a way to merge the two top-level directories
without getting a tree-conflict, in a single merge attempt without
having to checkout files or directories that are not involved in the
merge. Are there better approaches that I'm not thinking of?

Thanks for your help!

-Eric
Received on 2010-12-07 16:40:38 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.