You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "J. Armbruster" <su...@online.de> on 2006/04/23 18:37:54 UTC
SVN for embedded development?
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...
Re: SVN for embedded development?
Posted by "J. Armbruster" <su...@online.de>.
>
> 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.
I think up to now, it's 50-50... Svn has advantages (atomic commits and
so on) but when it lacks a basic functionality we need, there is no
(commercial) benefit from taking a new system...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN for embedded development?
Posted by William Nagel <bi...@stagelogic.com>.
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
Re: SVN for embedded development?
Posted by Seth Daniel <se...@speakeasy.net>.
On Mon, Apr 24, 2006 at 11:29:17PM +0200, Marcus Rohrmoser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> J. Armbruster wrote:
> > Somebody wrote something funny about it, that the "matrix" approach
> > wasn't understood by his wife, but the svn approach was understood.
>
> I like that one. Always thought svn is easy!
>
> Looks like what you look for is beyond svn functionality, some sort of
> overlaying or layering of directories/files.
I don't know that I have completely understood the requirements put
forth by the OP, but if you are looking for a layered approach perhaps
you or the OP should take a look at LaySVN.
http://people.debian.org/~erich/laysvn/
--
seth / @sethdaniel.org
Never underestimate the power of a small, tactical nuclear weapon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN for embedded development?
Posted by Marcus Rohrmoser <mr...@gmx-gmbh.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
J. Armbruster wrote:
> Somebody wrote something funny about it, that the "matrix" approach
> wasn't understood by his wife, but the svn approach was understood.
I like that one. Always thought svn is easy!
Looks like what you look for is beyond svn functionality, some sort of
overlaying or layering of directories/files.
I do think that's impossible with svn without going terrible detours. So
maybe svn is not for you.
Working in branches and keep merging has no appeal to me. Neither has
the external approach.
Greetings,
M
P.S.: Is your current tool publicly available? (I'm fine with the
housewife stuff, just being curious)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFETUMtpJZLwlH/3aERAnl2AJQNZJYb960OQNBEmRlXPqkJhEA9AJ0SxRvi
TgPBT8yUFxrJd1GI6Y8Q4Q==
=51JD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN for embedded development?
Posted by "J. Armbruster" <su...@online.de>.
>
>
> 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
>
Just before, I found exactly this thread... :-)
What I need, is something, somebody called "matrix"-organization.
Somebody wrote something funny about it, that the "matrix" approach
wasn't understood by his wife, but the svn approach was understood. But
what we need is not a housewife SCM, we (around 25 software developers)
need a SCM for professional embedded system development.
I try to explain our need in the attached gif.
What I see is, that the development of _each_ SCM I have seen is too
much centered on classical pc-application development, whre you just
have to deal with a very small number of branches. And that there is
always a main-line in development. They all struggle, when the
repository just have to provide a framework, where you put the suitable
functions out of it.
I think that I can get pretty much to the matrix structure with svn
externals- when I put everything what belongs together into a directory
and make a directory for each project. so far, this solves the
"collection" step.
Now, when I make sure that new branches are done by svn-copy, i have
pretty much what I want, with one exception: I want to log in a easy way
from some "base" revision of a module to each branch of it. as I see
it, this is only done by some extra work around. What I ask is now, when
SVN has a database-backend, why is it so a big hustle that something
knows that it has been copied? why does only the copy knows where it
comes from. Can somebody explain why this is like that?
Re: SVN for embedded development?
Posted by Jeffrey Creem <je...@thecreems.com>.
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