Hello!
We try to switch over our old fashioned source-code-repositories to some
newer system, and subversion might be a good choice!?
But trying to implement some use-cases I ran into some troubles, the
existing documentation does not discuss.
First, we development ECU software for automotive customers and
therefore we maybe have some special needs which common software
developer don't have.
I want to organize the repository and it seems that the suggested way to
work with trunk/tag/branch isn't suitable for our kind of application,
because there is no working trunk revision at all.
I try to explain: Our repositories (something like CVS or Clearcase) are
organized like this:
There is a file ignition.c. As everybody can imagine, the injection.c is
different for a car with 4 cylinders from that for a car with 6 cylinders.
So the ignition.c has it's own history, and the version for 6 or 4
cylinders are just branches on that file. If one makes a newer(better)
revision for the ignition 6 cylinder, he just puts a tag onto the new
version (eg.: IGN_6Cyl_V2) on the "6Cyl" branch.
The development for the ignition is fairly independent from the rest of
the things in the repository, but it needs to compile within a other
stuff.
When somebody wants to make a new delivery for a car, he just edits some
specification file and "collects" the tags he needs.
By archiving this specification, the progress of development is
documented. The Branches on the specification are named like the project
codes.
I tried to "rebuild" structure this with copied files like that:
first, in the trunk (which isn't more than a "container" for files) i
put a structure like this by using svn copy:
trunk
|-ignition_4cyl.c
|-ignition_6cyl.c
|-blahbla_fast.c
|-blahbla_slow.c
then I "svn copy" (can be done by a configure script) files from this to
the branches
branch
|-project_a
|-ignition.c -->ignition_4cyl.c
|-blahbla.c -->blahbla_fast.c
doing this, I run into some problems:
1. if a developer wants to make a change in a certain revision, he wants
to do it into project_a and not into the trunk, but in fact the trunk
revision should be updated.
2. after creating a copy subversion stops to log the changes for the new
revision, so log's are only backward, or do i misunderstand something ???
3. compared to CVS the handling of such a structure in subversion is
more complicated (=user acceptance!!!) than in CVS.
Does anybody know a easier way to organize our repository? Has anybody
faced these problems as well. (We do have up to 100-200 branches onto a
file, and have on each branch some dozen revision....)
Thank's a lot...
Received on Mon Apr 24 16:28:21 2006