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

Re: SVN for embedded development?

From: William Nagel <bill_at_stagelogic.com>
Date: 2006-04-24 16:47:37 CEST

On Apr 23, 2006, at 2:37 PM, J. Armbruster wrote:

> 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.

You might take a look at svnmerge (http://www.dellroad.org/svnmerge/
index). It provides some of the merge-tracking features that the
base Subversion system is currently lacking.

> 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 ???

If I'm understanding you correctly then that is a correct assessment.

Basically, given a file and a revision you can view the entire log
history of that file back to its beginning, including points where it
was copied from another file. For example, if you create a file
named A.c in revision 30, make some changes to it over several
revisions, then copy it to B.c in revision 75 the log for B.c will
show the history of all changes back through A.c in revision 30. On
the other hand, given A.c at revision 30, you can't do a reverse log
that will show it was copied to B.c at revision 75 and D.c at
revision 102.

> 3. compared to CVS the handling of such a structure in subversion
> is more complicated (=user acceptance!!!) than in CVS.

For this specific use case, you will likely find Subversion to be a
bit more complicated than the system you're currently using since SVN
wasn't specifically designed to support this use case well. On the
other hand you will likely find the overall SVN experience to be
enough better than your current system to justify the transition. It
really just comes down to how big a part of your process this
specific use-case is, and whether you have a development culture that
is willing to put some upfront effort into overcoming the inevitable
learning curve associated with any tool transition.

-Bill

>
> 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...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 24 16:49:02 2006

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.