Having the branch in a separate directory makes it easier
to keep track of what branch you're in.
That step is optional but Rom and I find it useful.
-- David
On 8/4/2017 3:10 AM, Richard Haselgrove wrote:
In that case, the workflow document linked by David earlier -
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains totally
unnecessary extra work steps:
* Clone branch: clone https://github.com/boinc/boinc.git into new dir w/
version num
* Right-click on dir; switch to new branch
* set version numbers in
* /: configure.ac, version.h, version.h.in, version.log
* in version.h, version.h.in: comment out pre-release with C syntax
* android: TODO; Oliver: textual representation, numerical value (increment) in
7.6, it's 146, so use 147
* commit
* create tag client_release/7.8/7.8.0
* git push, check "include tags"
The only reasons I can see for creating a new directory are:
To create clean build folders for the development tools to work in
To create an offsite archival backup in case of disaster
and both of those should be done *after* the version number updates and tagging
have taken place.
On Friday, 4 August 2017, 10:54, Charlie Fenton
<charl...@ssl.berkeley.edu> wrote:
Hi Oliver,
Perhaps I'm not understanding what you meant by "contains", but if I create a new branch named
"newbranch" from an existing branch named "oldbranch", then any commits made to oldbranch
after that are not included in a build I make using newbranch unless I specifically port them over, such as
by cherry picking them from oldbranch into newbranch or by merging one branch into the other. Is that not so?
I agree that your local repository always does contain all commits made to all branches as of the last time
you synced with the remote repository, so you can "check out" any branch or tag you wish. As I
understand it, checking out a branch or tag simply "hides" from your development tools anything
that is not considered part of that branch or tag, while "revealing" to your developer tools
everything that is considered part of the branch or tag.
This allows us to perform a build at any time from exactly the same source
files as were originally used to build the version represented by the tag. And
it allows us to build from a feature branch without including subsequent
changes made outside that branch, which can be useful while developing a
feature.
Since the client_release/7/7.8 branch was created from master and was then immediately
tagged as client_release/7/7.8.0, Richard is correct that, as a result of the way the
branch was created, all the Drupal source code up to that time became available in the
branch and under that tag, along with everything else in master at that point. I believe
that is what he meant by "included".
Cheers,
--Charlie
On Aug 4, 2017, at 12:45 AM, Oliver Bock <oliver.b...@aei.mpg.de> wrote:
On 03/08/17 17:03 , Richard Haselgrove wrote:
it also means that the whole of the Drupal source code was included in the
v7.8.0 'client' tag.
Just to avoid potential confusion: we're not using SVN anymore. A git
branch always "contains" the whole repo, not some copy of specific parts
of it.
Best,
Oliver
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
