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:
Sounds like something similar to what I wishI could do (though there are
some differences)
http://www.svnforum.org/2017/viewtopic.php?t=214&sid=85c9c884ec35cc111e1a4cd2242a833c
There are generally posts about something related to this every month or
two.
Usually someone points out that you could almost do something like this
with svn exernals (except it can't do files, only directories).
I've considered (if we never had to support windows) that perhaps this
could be done with a combination of symbolic links and externals.
What I have considered (and eventually rejected and just never migrated)
was something with an extra level of
directories where there is a new directory for each "revision history"
that I might want. Then, in the "root" of the directory there would just be
links to the appropriate subdirectory. Each of these subdirectories
would be managed with svn:externals.
The multiple "peer" trunks would really end up just controlling the
links and the actual files would only be in directories controled via
externals.
It clearly felt like (and was) an attempt to force a concept onto SVN
that it was not designed to support. This, combined with the way svn
externals works (commit at top level does not recurse into externals
directories) was enough to convince me it was not worth the effort.
Yes it would be possible to address this with some work and scripting
but in the end, there was no compelling reason to switch to something that
did not meet our needs.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 24 19:03:07 2006