My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 406: Gerrit replication write error for refs inside new directories
1 person starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  ----
Closed:  Jan 2010


Sign in to add a comment
 
Reported by di...@google.com, Jan 20, 2010
Affected Version: 2.1.1.1

Environment: In our setup we use directories inside the "refs/heads" dir to organize the various 
branches. So we may have things like "refs/heads/dir1/branch1", "refs/heads/dir1/branch2", 
"refs/heads/dir2/branch1", etc...

What steps will reproduce the problem?
1. Try to push (through Gerrit/SSHD) for a tag or a branch inside a directory that does not exist 
in the repository yet (for example "git push <repository> 
HEAD:refs/heads/somedir/somebranch")

What is the expected output? What do you see instead?
Should run fine, should be replicated automatically on the configured replication servers.

The command runs fine, the new ref shows on the local Gerrit filesystem (and can be fetched and 
used just as any other branch/tag) but then in the Gerrit error_log are messages about write 
errors when trying to replicate the new ref. I assume this is because Gerrit is trying to directly 
replicate the end file instead of also creating the intermediary directories if needed.

The problem is not high priority because it's solved by the cron job that rsyncs the git files and 
thus creates the necessary dirs and Gerrit replication works after that. It just leaves a certain 
window (the time between the branch with new intermediary dirs being pushed and the moment 
rsync runs) where the data might be lost if the Gerrit system hdd crashes.
Jan 20, 2010
#1 sop@google.com
Can you provide me more detail about your replication.config?
Perhaps send by private email if you can't publish a sanitized
version here.

The way the Git protocol works, we should automatically be
creating the intermediate directories as necessary, and also
delete them as necessary when they become empty.  The fact
that they aren't means your replication setup is broken, or
there is some sort of problem with the replication target's
permissions that is preventing the directories from being
created as expected.
Status: Accepted
Jan 21, 2010
#2 di...@google.com
It seems to be a problem created by pushing tags as branches. False alarm.
Jan 22, 2010
#3 sop@google.com
(No comment was entered for this change.)
Status: WontFix
Sign in to add a comment

Powered by Google Project Hosting