Attila Kinali wrote:
On Mon, 9 Nov 2009 07:53:44 -0800 (PST)
Patrick McNamara <[email protected]> wrote:
Releases do not belong in your source repository.
In a CM-theoretic way you are right. But...
In your "standard" CM/build/release environment, development
builds are done on some frequency. Depending on your release
process, either one of those development builds will be deemed
"releasable", or the decision will be made to make a separate release
build. The source that will go into the build will be denoted in some
fashion and the release build done off that source. The release binaries
will be denoted in the same fashion and placed in a release
"repository". The release binary is traceable back to the appropriate
source by its version/build number/some identifier that is part of the
binary itself. This identifier aligns with the identifier used to
select the source used to generate the binary.
... I don't worry about tracebility. We already have that in svn.
It might not be perfect, but it's more than just good enough.
Not sure how we would trace a binary release back to the SVN rev that
generated it without doing something similar. Being able to do that is
critical to being able to properly triage bugs. It is quite common for
people to get a bug report on an older release. They look at the
current release and find the problem doesn't occur and mark the bug
fixed or unreproducible. Many times the current release may have fixed
one case for that bug, or changed the logic slightly so that the trigger
conditions vary a bit from the original case. Either way, the bug
hasn't been fixed and further changes or different test cases end up
with more and more bugs being submitted.
Unless there is clear evidence that a bug have been fixed, the
investigation needs to be done against the source matching the binary.
This is even more important for what we do because a key method of
debugging is running simulations.
In this way, a binary release is always reproducible, just by knowing
its release identifier. The tooling used to generate the binary is always
an issue as it is required to be "archived" along with the release if you
need exact and absolute reproducibility. If not, then the above is enough
for most situations.
That's exactly what i'm worring about. We wont have the tools we have
today in a few years. And if we do not link source code and binary
in a strong way, we might lose the binaries ("who cares about these
old releases anyways?") and will not be able to reproduce them again.
I'm not really sure checking them in fixes the problem. What is to stop
someone down the road from "cleaning up" old cruft that is not needed
anymore? If they are important, they need to be treated as such.
Whether they are kept in the SVN repo or an FTP repo that is hosted
right beside the SVN one. If they are important, they need to be kept.
"Normal" CM tools generally use labels for identification in situations
like this. Subversion of course doesn't support labels. They closest it
comes is making a new tag. Not exactly the same thing, but perhaps
sufficient.
It is. Although at some point, most people wish that svn would have
real tags. But i have yet to see one issue where tags are not enough.
Attila Kinali
We'll the fact that I cannot easily see the source code that generated a
binary release if that release is checked in to the same SVN repo causes
all sorts of headache. If I select the rev of the repository that
contains the source, the binary hasn't been added yet and so won't be
loaded. If I select the rev where the binary was checked in, any
changes to the source that happened between the co/build and ci of the
build results will also be included. Because SVN tracks changes at the
repo level, labels, as supported in most tools, can't be implemented.
Anyway, we can easily go down a rat hole about SVN this an that. Let's
just say, I mirror the SVN repo into a local GIT repo that I do my dev
work in.
Sorry for the rant. I've spent my career do CM and CM related
activities in both hardware and software development shops and I have
had to deal with pretty much every problem imaginable and the side
effects of such. As such, I get somewhat "ranty" when it comes to CM
process. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
