Hi all,
There was a small bug in GetComponents when the EinsteinToolkit was released yesterday, which I would like to address with a patch. The bug occurs when you try to update a git repository; after pulling the latest changes, GetComponents tries to do a "git checkout $branch" again which errors because the branch has already been created when the repo was cloned. Note that this is really just a cosmetic error; it doesn't break anything and the repo stays on the appropriate branch.
Let me know what you think,
Eric
Index: GetComponents =================================================================== --- GetComponents (revision 653) +++ GetComponents (working copy) @@ -909,7 +909,7 @@ my $git_repo = $component{"GIT_REPO"}; my $cmd = ''; my $git_repos_dir = ''; - my $branch = defined($component{REPO_BRANCH}) ? $component{REPO_BRANCH} : 'master'; + my $branch = defined($component{REPO_BRANCH}) ? $component{REPO_BRANCH} : undef; # find a revision from $DATE my $date = defined $DATE ? '$'."($git rev-list --max-count=1 --before=$DATE $branch)" : $branch;
@@ -921,10 +921,12 @@ $cmd = "$git clone$shallow $url $ROOT/repos/$git_repo"; print_checkout_info($checkout, $url, $target, $name); run_command($cmd) == 0 or push (@components_error, $checkout); - chdir("$orig_dir/$ROOT/repos/$git_repo"); - run_command("git checkout $branch") == 0 or push (@components_error, $checkout); - run_command("git checkout $date") == 0 or push (@components_error, $checkout); - chdir("$orig_dir"); + if (defined $branch) { + chdir("$orig_dir/$ROOT/repos/$git_repo"); + run_command("git checkout --track -b $branch origin/$branch") == 0 or push (@components_error, $checkout); + #run_command("git checkout $date") == 0 or push (@components_error, $checkout); + chdir("$orig_dir"); + } $updated_git_repos{$git_repo} = 1; } # if git repo has already been cloned, we will pull the latest version @@ -932,8 +934,7 @@ chdir("$orig_dir/$ROOT/repos/$git_repo"); print_checkout_info($checkout, $url, $target, $name); run_command("$git pull -a") == 0 or push (@components_error, $checkout); - run_command("git checkout $branch") == 0 or push (@components_error, $checkout); - run_command("git checkout $date") == 0 or push (@components_error, $checkout); + #run_command("git checkout $date") == 0 or push (@components_error, $checkout); $updated_git_repos{$git_repo} = 1; chdir($orig_dir) @@ -996,9 +997,6 @@ chdir("$orig_dir/$ROOT/repos/$git_repo"); print_update_info($checkout, $url, $target, $name); run_command("$git pull -a") == 0 or push (@components_error, $checkout); - if (defined($branch)) { - run_command("git checkout $branch") == 0 or push (@components_error, $checkout); - } $updated_git_repos{$git_repo} = 1; chdir($orig_dir) } @@ -1706,6 +1704,7 @@ --status run status commands for each component --diff run diff commands for each component --root override root directory + --date checkout from a specific date --reset- authentication delete authentication files
@@ -1750,6 +1749,11 @@ Override the root directory in the component list. This allows checking out into an arbitrary directory.
+=item B<--date> + +Checkout components from a specific date. Currently only supported for cvs, svn, and mercurial. + + =item B<--reset-authentication>
Delete any CRL authentication files before processing the component list.
Hi Eric,
On Fri, Jun 18, 2010 at 03:51:21PM -0500, Eric Seidel wrote:
Let me know what you think,
The patch (please attach it as file next time) does not only fix the issue you mentioned, but also fixes some issues connected with the --date option. While this is great, it helps a reviewer to mention everything a patch does.
Having said that, the patch looks good and it didn't show the error message the old version did when I tested it. Nice work, please apply.
thanks, Frank
On Jun 18, 2010, at 19:54 , Frank Loeffler wrote:
Hi Eric,
On Fri, Jun 18, 2010 at 03:51:21PM -0500, Eric Seidel wrote:
Let me know what you think,
The patch (please attach it as file next time) does not only fix the issue you mentioned, but also fixes some issues connected with the --date option. While this is great, it helps a reviewer to mention everything a patch does.
Having said that, the patch looks good and it didn't show the error message the old version did when I tested it. Nice work, please apply.
To avoid confusion which version of "the" stable version people are using, we should probably accumulate several patches in the stable branch before releasing the next version, and then increase a version number (e.g. to ET_2010_06b). This isn't possible with the current setup, where people check out the tip of the release branch. In the future, we will probably want to point to a release tag, so that we can use the release branch for testing patches, and then create a new, different release tag once things work.
Most people won't update their stable version once they have it. If this patch is really important, we will need to announce it widely, and ask people to update if we decide it is important.
For the time being, I would hold off committing any changes to the release branch until we've discussed this in more detail. Eric, can you wait until Monday?
-erik
Hi,
On Sun, Jun 20, 2010 at 01:53:49PM -0500, Erik Schnetter wrote:
To avoid confusion which version of "the" stable version people are using, we should probably accumulate several patches in the stable branch before releasing the next version
I don't agree. It was my understanding that the stable branch can see changes if they were considered to be important enough. Assuming they are important enough to enter the stable branch I don't think it is a good idea to delay them.
There are two practices we could compare the ET with. One are releases of a typical program or library. Here each 'release' is a fixed blob of code, never to be changed again. If changes are necessary to a non-development branch there is still a new version number. The other practice is analog to security updates of a collection of software, like a linux distribution. As soon as an important (in this case security-related) bug is found it is corrected and clients are urged to update, keeping the version number the same.
I am leaning towards the second possibility: not delaying important patches and updating directly the release branch. That is why it is a branch, not a tag.
Most people won't update their stable version once they have it.
Then we need to tell them to do it.
For the time being, I would hold off committing any changes to the release branch until we've discussed this in more detail. Eric,
Agreed. We will have to discuss at least two patches on Monday. I will send details to the second in a separate email.
Frank
users@lists.einsteintoolkit.org