Gerald Combs wrote:
> Create a "/prerelease" directory in SVN, and copy the 0.99.1pre1
> revision to "/prerelease/wireshark-0.99.1pre1. (Bryant, will this
> meet your needs?)
Yes, it will. Thank you! Not to continue to nit-pick, but does
> For each prerelease, copy "/trunk-<version>" to
> "/prerelease/wireshark-<version>.pre<x>".
mean that it would be /prerelease/wireshark-0.99.1.pre1? (Note the extra
'.')
Having just gone through a (very) painful merging experience myself with
our project and subversion, I found it helpful to identify each "working
branch" (i.e. a place where commits are allowed) as either a "merge
from" (release) branch, or a "merge to" (feature) branch. In the
scenario you outline, I would assume that there are things that would
happen on trunk that would not necessarily happen on trunk-<version>,
but that everything on trunk-<version> would eventually be merged back
to trunk?
The thing that caused me pain on our last release is that people were
merging both directions - both from trunk to our release branch and from
the release branch back to trunk without any ordering concerns. Of
course subversion handled everything correctly - all the problems were
due to humans... ;-)
This was complicated by the fact that we were doing another
proof-of-concept release at the same time, and so bug fixes had to merge
from the release branch, to trunk, and then out to the POC branch.
I would also submit that if you are planning on having a stable API that
can be used by plugin developers (like myself), then you might consider
breaking that out as a separate structure that can be branched and
released on its own. This also allows for stricter rules enforcement on
that branch, so that changes to the stable API do not creap in and cause
incompatibilities.
Sorry again, I will happy with /prerelease/wireshark-0.99.1.whatever! No
response to the above expected.
Thanks again,
Bryant Eastham