Methodics have some interesting SVN tools in the IC space and the
website seems to mention continuous integration as a plugin to their
Cadence/Subversion integration.
www.methodics-eda.com
On Aug 31, 2009, at 6:59 PM- Aug 31, 2009, Brett Coon wrote:
> I work for a small company that is using subversion for version
> management of ASIC design files. The current way svn is used is for
> all development to occur in the trunk. Each designer checks files
> directly into the trunk when they feel their changes are good
> enough. There exists a set of tests, called the "sanity"
> regression, that designers are supposed to run before checking
> things in.
>
> The problem, of course, is that top-of-tree frequently breaks.
> People try to save time by only running part of the regression test
> suite, or they forget to check in all their changes so things pass
> in their work area but not for anybody else, etc. So we'd like to
> create more of a "release" model, where checkins aren't flagged as
> "good" until after they've passed a set of tests in a clean tree,
> and other designers won't see unreleased changes from others, unless
> they specifically request them.
>
> In prior companies, I've setup scripts to do this using CVS. We let
> designers directly check files into the main code tree, but to
> "release" files they ran a special script that would gather up their
> changes, run some tests, and if the tests pass apply a special
> "stable" tag to the files. CVS allowed you to sync your work area
> to tagged versions of files (I think CVS calls them "sticky" tags),
> but have individual sub-directories synced to the top-of-tree for
> commits.
>
> Now I'm trying to figure out how to apply this sort of flow to svn.
> I think it would be fairly easy to have a script that runs a
> regression, and if it passes, does an "svn copy <passing work area>
> http://.../tags/good_version" to update a tagged version of the
> tree. But then how do users make use of this tag? Seems like they
> could use "svn switch" to move their work area to the tagged
> version, but then their commits will change the tag, and we don't
> want that. We only want the script to be able to update the tag.
> I'm also reluctant to try any flow that requires people to use "svn
> switch", since my own experience with that command was less than
> pleasant (it's easy to really mess up your work area if you don't
> specify directories in the way svn expects them).
>
> Is there a way to "update" your tree to the versions of all files
> that are contained in a specific tag, but without "switching" your
> work area to that tag? Or am I going about this the wrong way? I
> realize svn doesn't really version individual files, but if a tag is
> by definition copies of files from various trunk revisions, then you
> can think of this as versioned files (e.g. each file has "a version"
> corresponding to its last change in the trunk).
>
> Is there an easy way to allow people to update parts of their trees
> to a tag, but then not be allowed to directly submit changes to this
> tag?
>
> The big caveat is that our svn users are not very advanced in the
> ways of svn. So we can't change much in their existing usage, e.g.
> asking users to create private branches and integrate their changes
> into the trunk would probably be asking too much.
>
> -Brett
>
> --
> Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390060
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-02 08:27:55 CEST