I noticed that in my developpment team, sometimes someone forgets to commit a file that must go with an other to keep the site working. this causes problemes and waste of time...
The question is : Is it possible to tell SVN tortoise : if someone tries to commit a file A without files (A1, A2,...An) ask them if they are sure they don't need to commit them too?
You need to have look at hooks.hook is nothing but a program triggered by some repository event.You can write whatever set of activities(alert in your case) inside hooks.use pre hooks for running the hooks before any task take place.
EDIT:
Refer commit monitor.CommitMonitor is a small tool to monitor Apache™ Subversion® repositories for new commits.
Related
I need to set up a pipeline for a branch that will do the following,
On push, it will trigger a pipeline (which happens as per GitLab)
1st Job to trigger a build (.net5) for the branch (new code pushed to the branch). If the build succeeds, it will begin the next job. However, I am to trigger build (MSBuild) on the runner location check out when the pipeline runs. But is there any way to directly run a build on the branch?
If the above build fails, the push should be reverted on a branch. I applied git revert and reset commands, but it only gets used to the build location of the runner. I need to revert commit at the branch level.
When GitLab starts a pipeline, it is a "detached HEAD" which basically means it creates a temporary branch that points to your specific commit. It does this because there might be a commit after it which the current build doesn't know about.
To get out of the detached head, you need to switch to the branch directly.
git checkout branch-name
To get the branch name, you find an appropriate predefined variable which works for your.
Once you have that, you need to get the latest version so you can revert. I usually needed the reset here to make things work.
git reset --hard
git pull
From there, you can revert. Now, the CI process doesn't have write permissions, so you need to have a GitLab access token with write permissions, which means you have to set up a new origin or parent.
git remote add changes https://oauth2:$PUSH_GITLAB_TOKEN#gitlab.com/group-name/project-1
git push -f changes branch-name
Now... that said, this is probably not what you want to do. Since you said you were new to CI, I'm going to say I'm 99.99999% sure you don't want to go down this path because it only leaves to heartache and frustration.
The reason is the branch may have a second or additional commit. It could be you missed something at the last minute and threw up a new one, an automated process starts up, or just your typical race conditions. Reverting a commit means you either will blow up with those changes or you end up erasing every other commit as you have to force push to get it up.
This also means that this is a very fragile process and will break many times, usually at the worst times (when you have a rapid series of commits), and then you have to tell everyone to stop working while you fix it.
(A good sign is how much work you have to do to fight the CI process.)
Instead, I recommend you create a merge request (MR) against your branch and set up the rules to make sure that is valid before you merge it into your branch. That way, the process doesn't have to worry about future or past commits, it just says what you have in your merge request (which is another branch) can't be applied after merging it with branch-name.
In our team, we have many branches (main, next, release/2.3.4, release/2.4.0, etc.) and doing MRs against each one has worked out well. We do the merge requests against each of the release branches, and the CI process says it can merge and pass tests before it tries to commit, but then we can commit knowing that 98+% of the time, it will be fine.
And it doesn't require jumping through hoops.
We recently migrated from using Subversion and Trac to Git and GitLab. We successfully migrated all of our old data.
I'm still trying to learn GitLab and generally like it better than Trac, but one thing I don't like as much is that when you reference a GitLab Issue in the git commit, it adds a reference and link to that commit under the issue, but you have to browse to the commit itself to see the associated Git commit message.
In Trac, we had it configured such that the Subversion commit messages were all displayed in the Trac ticket with the commit link, so it was easier to view all the relevant information for that ticket in one place.
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues? The message does show up in the commit list, but not on a referenced Issue.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
There is no built-in way to show the commit message of a crosslinked commit in the issue log. After all, commits are handled the same way as any other mentions: in the issue's history/mention log.
While the example in GitLab's documentation unfortunately misses the opportunity to show an example of a mention in the commit, here's an issue from GitLab itself with a mention. This commit also shows how mentions often get used within commits—with keywords:
Merge branch '65375-broken-master-gitlab-svg-path-test-failing' into 'master'
Update failing jest snapshot
Closes #13186
See merge request gitlab-org/gitlab-ee!14933
These kind of commits close the specific issue and don't require any further user action. Adding that kind of noise to the discussion/comment section of an issue is, in my opinion, only cluttering the discussion between actual humans*. However, the commit still shows up in the log and is clickable and hoverable.
To get back to your question:
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues?
If you hover over the linked commit, then you'll get the commit's subject. There's nothing more that can be achieved within GitLab itself.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
If you follow the usual commit/merge message based issue closing and use [Closes?|Fix(es)?] #issue in your commit message, you may end up with more noise in the comments than you would like too.
* well, except for some bots
I am wondering what happens in SVN when a file is updated directly instead of using SVN? The main reason I am asking is that there was a problem updating the SVN on my machine (windows) when the server (linux) had 2 names that were the same, but different case. I resolved this on the server, but didn't do it through SVN since it won't update correct, but I still get the issue. Do I need to run some kind of command to update it?
Thanks.
EDIT:
I deleted the comflicting file in the working direcotry and wanted to know if doing things directory in the working directory get tracked at all or what needs to be done to resync.
When SVN gets blocked because the repository is more "up to date" than the local checkout, one brain dead foolproof solution is:
Move (or remove) the files that are causing the conflict at the command line (don't use SVN tools to do this, and don't use the GUI if you have tortoise installed).
svn update the repository, which will restore the current copy of the files from the subversion server.
Decide what to do with your cached copies of the old files. Either manually merge them back into the repository, discard them, or remake the changes in the new svn managed files (depending on your needs).
Note that if you move the files into a directory using tortoise, make sure that you move it into a directory that's not associated with ANY SVN project. It's not fun trying to undo the helpful changes tortoise does in thinking your wanting a SVN move to accompany the file system move.
There is no need to run any special commands. If you updated the sources, the next time you will run svn update subversion will seamlessly merge the changes and you will get an uptodate working copy.
If you changed some files, they will appear modified or conflicted depending on the changes made by you and other users.
I just logged onto http://www.ezsvn.com, that hosts my SVN repository. I have been paying monthly for hundreds of commits.
They're shutting down, and their support is nonexistent.
Can I get a backup of my repository from my machine? I’m using Windows.
If you have shell access:
http://wiki.archlinux.org/index.php/Subversion_backup_and_restore
If you don't have shell access (look at both the original answer and also the comments re: svnsync):
http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/
If you have access to run svnadmin on their server, it'll be no problem, and I see Dav has already linked to instructions for that.
Now, if you don't have access to run svnadmin, as far as I know it's not possible to use the SVN client itself (maybe TortoiseSVN for you) to copy the entire repository. (EDIT: never mind, I guess that was wrong. I'll leave the git info here just for the fun of it though.) But you can convert a whole Subversion repository to git, and here are instructions for doing that: http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/ From there, you might be able to convert the git repository back into an SVN repository on another server. I know it's not really the answer you were looking for but if nothing else works, it will at least let you save your project's history in some form. (And hey, you could take it as an excuse to switch to distributed version control, which is all the rage these days)
If you really want/need the full history of your repository, you'll have to either get a dumpfile from the provider or get it yourself - some of the responses so far have addressed this already.
Another option: if you are not concerned with past revisions, but want your repo at it's latest state, just checkout the head revision, and export it to a separate location on your computer. That way, you have all your work to this point. You could then keep that as a backup, or possibly create an SVN account elsewhere, and import the exported copy into a fresh repo, then you would be back in business.
In linux, how do I check if someone has not yet committed something?
I remember I made changes on a server once..but forgot to commit. Now, I don't know which server I used to make those changes.
It isn't possible to tell if someone else has uncommitted changes in their working copy, because the status of the working copy of each user isn't sent to the repository.
SVN servers/repositories don't keep track of changes made on clients. You'd need to locate all the possible places where the client changes might be and check for modifications there.
This is one of the tradeoffs of not having the server keep track of everything like Perforce does. On the other hand, having the server keep track of everything can be a pain at times.
A local working copy is just that, local. The Subversion repository can't know which client has uncommitted changes.
FWIW, you can check a local working copy status using svn st
svn help st
There is no way to tell if anyone other than yourself has checked out a revision and made changes which have not been committed. The only way to find out is to login as each user and execute svn status in the appropriate directory.