You will have to import the project "behind the scenes". As the server
administrator, just push directly into the server managed repository.
Or cd into it and execute `git fetch URL HEAD:refs/heads/master` to
fetch directly into the repository.
Hi Andrew,
On my $DAYJOB I saw a lot of those problems as well (when you go to the change webpage you get a big NOT FOUND instead of a change.) when we upgraded from 2.1.6 to 2.1.7/2.1.8.
Every time you try to upload a change or patch set, starting with 2.1.7, Gerrit checks all other changes/patch sets in the same git like you describe. The trick is to convince it to stop looking at these broken open changes.
What we did was we did a little database-hacking for each of the changes that affects uploads; we had to change them to the abandoned state manually in the database, since the webpage is no longer available.
Now, if we look at the database for 2.1.x we find that changes has its own table with the following fields:
Table "public.changes"
Column | Type | Modifiers
----------------------+--------------------------+---------------------------------------------------------------------
created_on | timestamp with time zone | not null default '1900-01-01 00:00:00+01'::timestamp with time zone
last_updated_on | timestamp with time zone | not null default '1900-01-01 00:00:00+01'::timestamp with time zone
sort_key | character varying(16) | not null default ''::character varying
owner_account_id | integer | not null default 0
dest_project_name | character varying(255) | not null default ''::character varying
dest_branch_name | character varying(255) | not null default ''::character varying
open | character(1) | not null default 'N'::bpchar
status | character(1) | not null default ' '::bpchar
nbr_patch_sets | integer | not null default 0
current_patch_set_id | integer | not null default 0
subject | character varying(255) | not null default ''::character varying
row_version | integer | not null default 0
change_id | integer | not null default 0
change_key | character varying(60) | not null
topic | character varying(255) |
Looking at the definition of this table, we see open and status, they're interesting to us.
So, what values can they have?
reviewdb=> select status from changes group by status;
status
--------
M
n
A
s
(4 rows)
reviewdb=> select open from changes group by open;
open
------
Y
N
(2 rows)
reviewdb=>
Those values in status have meanings which come into play in our problem.
The upper case letters represents states in closed changes, so they'll only exist together with the N-state in open, and vice versa with lower case letters.
M = merged
A = abandoned
s = submitted/queued for merge
n = not submitted
So, when querying your own database, you'll find that the changes showing up in the server log as broken will be in state (open=Y, status=n), and to close them we have to change them to (open=N, status=A).
In conclusion then, run this SQL line for each of your broken changes:
reviewdb=> update changes set (open, status) = ('N', 'A') where change_id = MY_BROKEN_CHANGE_ID_NUMBER;
In this example, please check the syntax of the SQL one time extra (instead of trusting me blindly that is), as well as replace the string MY_BROKEN_CHANGE_ID_NUMBER with an actual change_id number. :-)
Oh, and there might even be more broken changes surfacing once you've fixed the first ones that's causing trouble. I recommend you take a developer that has problems uploading and ask him to upload repeatedly while fixing the ones that show up to just get through them all quickly.
Good luck, and I hope your devs will be able to upload themselves shortly. J
--
Best regards,
Fredrik Luthander
Sony Ericsson Mobile Communications AB
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en