You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brett Coon <br...@gmail.com> on 2009/09/01 01:59:46 UTC
Looking for ideas for a tag/release svn usage model
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=2389606
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Les Mikesell <le...@gmail.com>.
Brett Coon wrote:
> On Tue, Sep 1, 2009 at 12:32 PM, Bob Archer <Bob.Archer@amsi.com
> <ma...@amsi.com>> wrote:
>
> >I understand that. My question is whether or not there's an easy
> way to update an entire work area to a /mixed /set of versions, e.g.
> a one->line way to do the equivalent of:
>
> >svn update -r1234 somedir/
> >svn update -r1210 somedir/weirdfile.x
> >svn update -r2111 otherdir/dira
> >svn update -r2012 otherdir/dirb
>
> Why would you want to do that? Generally you want to update to HEAD
> every time.
>
> I would want to do that if those specific versions were the most recent
> versions that were known to work correctly together (e.g. passed some
> level of regression testing).
>
> Ideally, those versions /would /be identical to HEAD most of the time,
> since all checkins would pass the regression tests.
>
> Again, what I'm looking for is a way to update my work area to the
> newest "blessed" version of each file, even if that version happens to
> not be HEAD. It seems there is no directly-supported means to do this.
Can't you (a) copy the known-working (or release) versions to tags for
more sensible reference names, and (b) use externals to pull them into
the appropriate place in your workspace?
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389972
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Looking for ideas for a tag/release svn usage model
Posted by Bob Archer <bo...@amsi.com>.
>>I understand that. My question is whether or not there's an easy way to update an entire work area to a mixed set of versions, e.g. a one->>line way to do the equivalent of:
>>svn update -r1234 somedir/
>>svn update -r1210 somedir/weirdfile.x
>>svn update -r2111 otherdir/dira
>>svn update -r2012 otherdir/dirb
>Why would you want to do that? Generally you want to update to HEAD every time.
>I would want to do that if those specific versions were the most recent versions that were known to work correctly together (e.g. passed >some level of regression testing).
>Ideally, those versions would be identical to HEAD most of the time, since all checkins would pass the regression tests.
>Again, what I'm looking for is a way to update my work area to the newest "blessed" version of each file, even if that version happens to >not be HEAD. It seems there is no directly-supported means to do this.
Do you not create release tags/branches?
You could always create a folder in your project that uses pegged externals.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389948
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Brett Coon <br...@gmail.com>.
On Tue, Sep 1, 2009 at 12:32 PM, Bob Archer <Bo...@amsi.com> wrote:
> >I understand that. My question is whether or not there's an easy way to
> update an entire work area to a *mixed *set of versions, e.g. a one->line
> way to do the equivalent of:
>
> >svn update -r1234 somedir/
> >svn update -r1210 somedir/weirdfile.x
> >svn update -r2111 otherdir/dira
> >svn update -r2012 otherdir/dirb
>
> Why would you want to do that? Generally you want to update to HEAD every
> time.
>
I would want to do that if those specific versions were the most recent
versions that were known to work correctly together (e.g. passed some level
of regression testing).
Ideally, those versions *would *be identical to HEAD most of the time, since
all checkins would pass the regression tests.
Again, what I'm looking for is a way to update my work area to the newest
"blessed" version of each file, even if that version happens to not be
HEAD. It seems there is no directly-supported means to do this.
-Brett
--
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389946
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Looking for ideas for a tag/release svn usage model
Posted by Bob Archer <bo...@amsi.com>.
>I understand that. My question is whether or not there's an easy way to update an entire work area to a mixed set of versions, e.g. a one->line way to do the equivalent of:
>svn update -r1234 somedir/
>svn update -r1210 somedir/weirdfile.x
>svn update -r2111 otherdir/dira
>svn update -r2012 otherdir/dirb
Why would you want to do that? Generally you want to update to HEAD every time.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389902
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Brett Coon <br...@gmail.com>.
Thanks for the response. Comments below:
On Tue, Sep 1, 2009 at 2:33 AM, Bolstridge, Andrew <
andy.bolstridge@intergraph.com> wrote:
> Given all of your requirements, I think you do need to use SVN branches,
> however – create a branch that is the ‘development trunk’, let users commit
> to that. Then after their changes have been verified, someone else (eg a
> build manager) merges the dev trunk to the “release trunk”. This way,
> developers use their existing model – they just use a particular directory
> in SVN, and your verified designs are retrieved from the guaranteed-ok
> directory.
>
Am I correct that it would work just as well to leave developers on the main
trunk, and to create a "release branch" that is the target of periodic
merges? I suppose that doesn't get users "warmed up" to the idea of using
branches, but has the advantage of not requiring any change at all from
today's usage.
But I still don't see how this makes it easy for users to update their work
area to contain the *release *versions of all files except the ones they're
working on, which are development versions.
I'm used to the idea of tags as being user-friendly names for per-file
version numbers. So if you say "svn update -r*tagname*", you might get
version 1234 of file foo.x, but version 2341 of file bar.x. Either way,
your files are still in the same development trunk or branch they were in
before the update.
Here's an example: a user recently made the classic mistake of forgetting
to checkin one of her changes (and doing this on a Friday evening, no
less!). So people who updated their trees couldn't build. The workaround
was to grab an older version of one of the new files, to avoid dependencies
on the missing checkin. In other revision management tools I've used, one
user could manually adjust file versions to get a working tree (in this case
by grabbing an old version of that specific file), and then apply a "tag" to
all files to label these versions as good. Other users could then sync
their work areas to the tagged versions, and remain on the main development
line. I see no way to do the equivalent in SVN. Since tags are pretty much
the same as branches, which are entire parallel directories, there doesn't
seem to be a notion of "stay on the trunk, but update to a named collection
of file versions".
> The only person who has to worry is the build manager, but he will know
> what he’s doing with SVN. Once people have gotten used to this approach, you
> can start letting them have their own branches, and things will be SVN
> heaven.
>
Guess I'm not sure how well "SVN heaven" matches my own vision of "revision
management heaven" :)
> You can still ‘tag’ a revision by remembering the revision number, it’s a
> pity SVN doesn’t have support for giving these numbers a human-readable name
> (and IIRC someone submitted a patch for just that) as it would have solved a
> good deal of similar issues. The canonical svn approach is to use ‘tag’
> branches for tagging. (personally, I feel that just clutters the repository
> up, especially if you release very often).
>
I agree.
> You can update your working copy to a particular revision – just specify
> the revnum in the update command.
>
I understand that. My question is whether or not there's an easy way to
update an entire work area to a *mixed *set of versions, e.g. a one-line way
to do the equivalent of:
svn update -r1234 somedir/
svn update -r1210 somedir/weirdfile.x
svn update -r2111 otherdir/dira
svn update -r2012 otherdir/dirb
...
-Brett
--
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389855
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Looking for ideas for a tag/release svn usage model
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
Given all of your requirements, I think you do need to use SVN branches,
however - create a branch that is the 'development trunk', let users
commit to that. Then after their changes have been verified, someone
else (eg a build manager) merges the dev trunk to the "release trunk".
This way, developers use their existing model - they just use a
particular directory in SVN, and your verified designs are retrieved
from the guaranteed-ok directory.
The only person who has to worry is the build manager, but he will know
what he's doing with SVN. Once people have gotten used to this approach,
you can start letting them have their own branches, and things will be
SVN heaven.
You can still 'tag' a revision by remembering the revision number, it's
a pity SVN doesn't have support for giving these numbers a
human-readable name (and IIRC someone submitted a patch for just that)
as it would have solved a good deal of similar issues. The canonical
svn approach is to use 'tag' branches for tagging. (personally, I feel
that just clutters the repository up, especially if you release very
often).
You can update your working copy to a particular revision - just specify
the revnum in the update command.
Andy
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389707
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Les Mikesell <le...@gmail.com>.
Brett Coon wrote:
>
> Alas, disk space always seems to be an issue in the ASIC world.
> Developers work on network filesystems, so you can't just stick a 500GB
> disk in their desktop machine and be done with it. Simulations aren't
> interactive, which means they dump massive log files in your work area.
> Every design company I've worked for has battled disk space issues, with
> one of the big problems being multiple trees in user directories. In a
> prior company that will remain nameless, the default user disk quota was
> only large enough to build and run simulations in a single branch. You
> could double that space with manager approval, but it was still tight...
Yet another reason to push the grunge work of building and automated
testing off to something like hudson. It can notice that you have new
commits and spin off the jobs to slave servers that have the appropriate
resources. You might need per-developer branches to keep the untested
stuff out of sight in that scenario, though.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389905
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Brett Coon <br...@gmail.com>.
On Tue, Sep 1, 2009 at 11:07 AM, David Weintraub <qa...@gmail.com> wrote:
> I would be careful about creating a separate "release" branch because you
> end up taking pressure off of the developers about getting their code to
> work.
>
> I believe in the "Finger o' Blame". Whenever something goes wrong, the
> Finger o' Blame points to the scapegoat... I mean culprit. Right now, if the
> build breaks, the Finger o' Blame swings around and points to the developer
> who did the checkin. By creating a release branch, you are now personally
> responsible for the code on the release branch. If bad code gets put on
> there, the Finger o' Blame now points to you.
>
The model I prefer is for the submit system to reject failing "release"
submissions and bounce them back to the developer who submitted them. Blame
isn't always very effective. In fact, I've found that the developers who
respond best to blame are also the ones who least frequently make bad
checkins to begin with. Guess it makes sense.
Do you have a continuous build system like Hudson or Continuum? Those will
> do a build every time a commit is done. They will also show you who did the
> change, what was changed, and why. Hudson will give you a link to the last
> good build artifact for testing, so QA knows where to find the build to
> test.
>
Nope. I'll look into these. Keep in mind this is an ASIC design
environment, where build tools tend to be very primitive. What we have now
is a primitive perl script to run a set of design simulations and count the
number of failures. All development is done on Linux machines, with builds
and simulations being farmed out to networked computers (using Sun grid
tools for job management). I'm not sure if any of these continuous
integration tools can handle such an environment natively, though of course
anything is possible with enough customization.
Hudson also reports the Subversion revision number used for the build. Many
> shops use that instead of a build tag which makes updating easier because
> you can simply use the revision number instead of switching to a tag. By the
> way, checking out tags can be a problem because it is extremely easy for a
> developer to commit changes on a tag without anyone realizing it! I have a
> pre-commit hook I use that allows users to create a tag, but be unable to
> actually modify that tag.
>
Yes, this is one of my concerns about using Subversion tags they way I've
used tags in the past.
In fact, I don't even like the "switch" command because developers get
> confused which branch they're working on and end up putting changes into the
> wrong branch.
I don't like "switch" because it's really easy to "switch" one directory
into an entirely different location, or otherwise mess up your work area.
And I agree that properly-switched directories can be very confusing.
> I usually prefer if the developer creates a working copy for each branch
> just because it will cause less confusion. And, with 150 Gigabyte disks,
> disk space shouldn't be an issue.
>
Alas, disk space always seems to be an issue in the ASIC world. Developers
work on network filesystems, so you can't just stick a 500GB disk in their
desktop machine and be done with it. Simulations aren't interactive, which
means they dump massive log files in your work area. Every design company
I've worked for has battled disk space issues, with one of the big problems
being multiple trees in user directories. In a prior company that will
remain nameless, the default user disk quota was only large enough to build
and run simulations in a single branch. You could double that space with
manager approval, but it was still tight...
-Brett
--
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389889
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Les Mikesell <le...@gmail.com>.
David Weintraub wrote:
> I would be careful about creating a separate "release" branch because
> you end up taking pressure off of the developers about getting their
> code to work.
That sort of depends on the culture and interaction between developers,
though. If you have rapid changes and multiple developers in the same
project, the trunk is sometimes going to be broken and you are better
off recognizing that than slowing down work or discouraging developers
from committing early so other can start using their new features. But
you have to do some QA before releases, and a release branch is the
place to do it.
> I believe in the "Finger o' Blame". Whenever something goes wrong, the
> Finger o' Blame points to the scapegoat... I mean culprit. Right now, if
> the build breaks, the Finger o' Blame swings around and points to the
> developer who did the checkin. By creating a release branch, you are now
> personally responsible for the code on the release branch. If bad code
> gets put on there, the Finger o' Blame now points to you.
As it should, if you are the person doing QA.
> I've gone the release branch route before. What happens is that it takes
> pressure off the developers to make sure their code works. If a build
> breaks, they simply say they're in the middle of something important,
> but they'll get it fixed as soon as they can. If you talk to their
> manager, the manager will side with the developer. Why are you so
> concerned? The release code is still good.
>
> Sooner or later, either by chance, or decree (last minute fix needs to
> be sent to the customer!), that release build will break, and it will be
> your fault for putting bad code on the release branch. The whole shop is
> now in a tizzy because a release needs to be done, and because of your
> incompetence, the release can't be built.
Someone has to have the authority to say something should or shouldn't
be released... Maybe you don't want to be in that position, but just
shipping the trunk isn't likely to be better.
> Do you have a continuous build system like Hudson or Continuum? Those
> will do a build every time a commit is done. They will also show you who
> did the change, what was changed, and why. Hudson will give you a link
> to the last good build artifact for testing, so QA knows where to find
> the build to test.
Yes, Hudson is great and integrates nicely with subversion. If you have
automated unit and acceptance tests, let it do the grunge work for you.
> Hudson also reports the Subversion revision number used for the build.
> Many shops use that instead of a build tag which makes updating easier
> because you can simply use the revision number instead of switching to a
> tag. By the way, checking out tags can be a problem because it is
> extremely easy for a developer to commit changes on a tag without anyone
> realizing it! I have a pre-commit hook I use that allows users to create
> a tag, but be unable to actually modify that tag.
Hudson can even create 'good' tags for you when a build and tests
complete successfully - but you can also just work with the revision
numbers.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389872
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by David Weintraub <qa...@gmail.com>.
I would be careful about creating a separate "release" branch because you
end up taking pressure off of the developers about getting their code to
work.
I believe in the "Finger o' Blame". Whenever something goes wrong, the
Finger o' Blame points to the scapegoat... I mean culprit. Right now, if the
build breaks, the Finger o' Blame swings around and points to the developer
who did the checkin. By creating a release branch, you are now personally
responsible for the code on the release branch. If bad code gets put on
there, the Finger o' Blame now points to you.
I've gone the release branch route before. What happens is that it takes
pressure off the developers to make sure their code works. If a build
breaks, they simply say they're in the middle of something important, but
they'll get it fixed as soon as they can. If you talk to their manager, the
manager will side with the developer. Why are you so concerned? The release
code is still good.
Sooner or later, either by chance, or decree (last minute fix needs to be
sent to the customer!), that release build will break, and it will be your
fault for putting bad code on the release branch. The whole shop is now in a
tizzy because a release needs to be done, and because of your incompetence,
the release can't be built.
Do you have a continuous build system like Hudson or Continuum? Those will
do a build every time a commit is done. They will also show you who did the
change, what was changed, and why. Hudson will give you a link to the last
good build artifact for testing, so QA knows where to find the build to
test.
Hudson also reports the Subversion revision number used for the build. Many
shops use that instead of a build tag which makes updating easier because
you can simply use the revision number instead of switching to a tag. By the
way, checking out tags can be a problem because it is extremely easy for a
developer to commit changes on a tag without anyone realizing it! I have a
pre-commit hook I use that allows users to create a tag, but be unable to
actually modify that tag.
In fact, I don't even like the "switch" command because developers get
confused which branch they're working on and end up putting changes into the
wrong branch. I usually prefer if the developer creates a working copy for
each branch just because it will cause less confusion. And, with 150
Gigabyte disks, disk space shouldn't be an issue.
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389852
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Looking for ideas for a tag/release svn usage model
Posted by Listman <li...@burble.net>.
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@subversion.tigris.org].