What is the best script for a SVN Pre commit to only allows commits that contain the following string
issue 1234
This is to help our build system tag the ticket in our bug system while talking to the svn repo
Something like
if comment includes
issue 1234
then commit
otherwise
fail "please enter issue "
This is for a SVN linux configuration
There is a great pre-commit log entry query example shown at http://blog.grimsy.net/2008/07/a-few-svn-pre-commit-hooks/
Related
I have received a gitlab alert mail stating that "One project failed its last repository check".
I did check the error in Gitlab admin panel as "Last repository check (just now) failed. See the 'repocheck.log' file for error messages." As suggested in Admin Panel in Gitlab, i have checked the repocheck.log file and the error is as below.
"Could not fsck repository: error: Could not read 0f188244898707e6090498bc03aafd8ac25e776e
failed to parse commit 0f188244898707e6090498bc03aafd8ac25e776e from object database for commit-graph
error: Could not read 4ab7111f3f8f1083cee8e33ec033c18edfefb0e9"
This happened the same with another repo last week. Even that had similar error message and it is not resolved yet. Tried to clone the same repo in another gitlab instance to recreate the issue but the repo check there seems to be fine.
Unable to find proper solution for that. Could any one please help on this.
It seems to be an active issue: https://gitlab.com/gitlab-org/gitaly/-/issues/2359#note_966195929 The issue is a couple of years old, but the note I link to, has updates from today, including info on fixes and workarounds.
In any case: The commit-graph is a relatively new feature and since it is a form of index into packed data, it can be recreated. So the corrupted repo can be easily fixed without loss of data.
It can be reproduced like this:
Visit a commit graph: Project sidebar / Repository / Graph
Delete one of the visible commits by rewriting history:
git checkout <branch>
git reset head~1
git commit -am "Replace last commit with a new one"
git push --force
Refresh the page of step 1
Now GitLab will send you "A commit graph at GitLab projects failed their last repository check" when it runs the repository check on a scheduled interval.
I'd consider it a bug that admins and maintainers get a warning about this, since nothing is wrong really. See the GitLab issues linked by Anders Bandholm for more details.
I've now come across and fixed this twice, I found the fix on the forum:
Find all your failed repos at your instance's admin panel: https://your-gitlab-instance/admin/projects?last_repository_check_failed=1
Open the repo from that page and copy down its Gitaly relative path, it should look like #hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git
NOTE! The following commands should be run with the user that gitlab runs as. You can do this with sudo su [username], in my case the username was git. They will work with sudo, but it may create files or folders that the gitlab user won't be able to access.
Run the fsck command using the repo's relative path (This should output the same text as your /var/log/gitlab/gitlab-rails/repocheck.log file):
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/[Gitlab relative path] fsck
# example
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/\#hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git fsck
Run the gc command using the repo's relative path. This may take a minute to complete.
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/[Gitlab relative path] gc
# example
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/\#hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git gc
Run the fsck command again from step 3 to check that the command was successful
On the repo's page from step 2, click the blue Trigger repository check button
I am running my own instance of a Gitlab-CE server with the following fairly-up-to-date specs:
Gitlab Version 10.8.4
Gitlab Shell 7.1.2
Gitlab Workhorse v4.2.1
Now my problem is that when I add a message to my commits referencing an issue, there is no commit mention in the issue as there should be.
As an example: git commit -m "handled issue #12" and the obligatory git push does not add anything to issue 12.
Any idea as to where the problem could be?
Edit: added the information that I am already pushing to the remote.
Found it: turns out that I had forgotten to change back my email adresse back to the one used in the remote repo – I had it changed locally a few weeks ago to test s.th.
So due to using my ssh key committing worked, but it showed the wrong user in my commits (which should have been a good hint for me as to what's up...) and due to that user not being a member of the project I had no access to the issues (at least that's my conclusion here).
Hope this might help anyone silly enough to run into similar issues...
git commit just creates a local commit in your branch. If you want GitLab to be aware of it, you need to push it:
$ git push origin my-branch
I spend my day doing this:
Read an issue on a Gitlab-powered issue tracker,
Fix the issue,
Commit and push to the same Gitlab-powered Git server,
Mark the issue as closed.
To remove the 4th step, how can I close the issue automatically when committing?
Commit and push using this syntax:
git commit -m "Sort more efficiently" -m "Closes #843"
git push
This will commit and close the issue.
Note that unlike Github a single -m will not work.
The following will appear on the issue page:
References:
https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically
How to commit a change with both "message" and "description" from the command line?
According to this link from gitlab, you will be able to do that with a variety of words such as "fixes" or "closes". It does not need to be in a seperate line.
So you could have the following message:
Fixes #20. I had to replace "foo" with "bar".
And that will close issue #20.
I have a Subversion repository (running SVN 1.6.6) on an Ubuntu Linux server, and I'm trying to create a branch using the TortoiseSVN GUI; However, I get an error back:
COPY c:\work\repositoryWorkingcopy\ to http://svnserver/svn/repository/Oct13, Revision HEAD
Error
'/svn/repository/!svn/bc/234/branches'
path not found
I logged into my Linux box to see if the "branches" folder was NOT available. However, I could see that /var/svn/repository/branches existed.
So, what's the problem and how do I fix it?
I tried the following command (as per http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1) as well as from the command line and got a similar error:
c:\workingcopy> svn copy http://reposerver/svn/repository/ http://reposerver/svn/repository/branches/BFI_Oct13/ -m "Creating a branch"
svn: '/svn/repository/!svn/bc/235/branches' path not found
What should I do?
Also, svn info on the main directory of the working copy gives the following information.
Path: .
URL: http://reposerver/svn/myrepository
Repository Root: http://reposerver/svn/myrepository
Repository UUID: 7a31d3c0-b288-4695-aecd-3f9dda2861ab
Revision: 235
Node Kind: directory
Schedule: normal
Last Changed Author: anjan
Last Changed Rev: 235
Last Changed Date: 2010-10-13 20:39:31 +0530 (Wed, 13 Oct 2010)
When you say:
I logged into my Linux box to see if the "branches" folder was NOT available. However, I could see that /var/svn/repository/branches existed.
Do you mean that the actual directory exists in the filesystem (which will do you absolutely no good), or that it exists in the repository?
Possible fix:
$ svn mkdir http://reposerver/svn/repository/branches
$ svn copy http://reposerver/svn/repository/ http://reposerver/svn/repository/branches/BFI_`date +%b%d`/ -m "Creating a branch"
Generally speaking, you'll want to branch on the server, make your changes in the branch, and check those changes in.
So, the first step is to create the branch, which is just a copy command. In TortoiseSVN, you need the URL to (presumably) the trunk, and you'll need to define the URL of the branch. In a more standard repository setup, the trunk might be http://svnserver/svn/repository/trunk and your branch might be http://svnserver/svn/repository/branches/Oct13.
Then, you'll want to switch your working copy to the branch. You should have the option to do so without losing your local changes.
Finally, you would check your changes in, and they should go to the branch from there.
I'm more accustomed to the command-line interface for SVN, but I have used TortoiseSVN. It's been a while, though, so leave a comment if you still have trouble or this doesn't make sense.
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working