I have faced the error
remote: Hello there! We have restricted the binary files (.exe, .dll, .zip, .7z, .deb, .cab, .gz, .pkg, .iso) that are pushed into GitLab.
while try to push the .dll file into GitLab.
I tried to remove the .dll file type from the git ignore file list but i could not find the document gitignore_global.txt which is directory was represented in,
Gitlab: Tools->Options->Git tab->Edit file.
Kindly let me know If the document was not present then where from the ignore-able list was get and how can i skip .dll files from those list.
Unless you are running your own server (and the admins, if not you, change the push rules), you won't be able to push any of those file types. Those 9 are selected since generally those are very large files and shouldn't be stored in git.
If you run your own Gitlab server though, and absolutely need to store the .dll file in git, you can adjust the push rules in the Admin area. See the docs here: https://docs.gitlab.com/ee/push_rules/push_rules.html#enabling-push-rules
Related
I want to use the git-branch npm module to detect my branch in the code, but Heroku doesn't show the .git folder, so git-branch displays an error.
Is there a way to make that I can access that file?
If not, can I use a workaround, like copying the file and then restoring it, or stuff like that?
I'm auto-deploying from GitHub a Node.js app.
No, there is no way. Heroku will not send the .git folder to the build.
Even if that folder were kept, you would always see the master branch though, as it's always what you push to.
However, you can still retrieve the pushed GIT commit (not the branch) using the dyno metadata feature, which will set environment variables with various informations about your app. HEROKU_SLUG_COMMIT will be the commit you deployed.
I'm moving my current server contents to a new one, and am currently in the process of setting up SVN. I'm fairly unfamiliar with SVN, typically using it to the extent of commits and updates.
I have two locations that I use SVN on the old server:
PROD location:
/var/www/html/new_dwutils/
and local:
/home/{user_name}/public_html/new_dwutils/
My interaction svn-wise is normally committing and updating at the /new_dwutils/ level.
Note: Running svn --version says I'm at version 1.6.11 for both servers.
I'm now trying to recreate this structure on the new server. My initial thought was to create the svn repo using something like:
svnadmin create /var/www/html/new_dwutils/
This creates the repo dir, but, when I copy my files into the dir, I am unable to do svn commands like status. However, when I go into a sub-dir of the copied data, I can use the svn commands.
This has me thinking that the repo is /new_dwutils/ and the copied data is considered a project? And the sub-dirs are working copies then?
Going off that thought, I deleted the repo, and made the html dir a repo:
svnadmin create /var/www/html/
I then copied my new_dwutils dir, and sure enough, I was able to do svn commands like I use too. What I've noticed is that when creating the repo, a few things are added that were not on the previous server: conf/, db/, format, hooks/, locks/, and README.txt. I get that these are svn files, but I'm not seeing the .svn file. I know that there was an update for svn that "removed" .svn files, but these files are now in /var/www/html/.
Now I want to setup my local working copy.
I've been doing (location /home/{user_name}/public_html/):
svn checkout file:///var/www/html/
Problem is it copies the html/ file, but nothing in it, and I don't want the html/ file I want the html/new_dwutils/ file.
I feel like I'm doing it wrong from the start, and would greatly appreciate some explanation on how to get on the right track. A step by step would be extremely useful, and if further clarification is need for files or directory paths, I would gladly detail.
Thanks!
The Subversion Manual will answer all of your questions.
If you're making a Subversion repository under /var/www.html, I'm assuming you're using Apache httpd as your server. Look at Chapter 6. If you already have a repo, create a dump file, then use that dump file to recreate the repo. Look at Chapter 5 on moving repositories.
If you don't know anything about Subversion, or are confused by the difference between the repository location directory and a working directory, read the on-line manual. It's one of the best pieces of documentation I've seen.
From description of your question it appears that '/var/www/html/new_dwutils/' is your working copy and not a repo.
Go to '/var/www/html/new_dwutils/' on the old server and type "svn info" this should give you location of the old repo. You should simply be able to 'svn co ' into the new location to checkout a copy of all your files from the old server (everything that is checked in - you will not get anything that is not checked in on the old server).
However, if your repo was local on the old server and you want to move it to your new server too. Then you can simply copy the entire folder to the new server and access it directly using its new location in 'svn co' command.
I created a new project in svn svnadmin create /myrepo in my server, with my client I did a checkout and add new files, later a commit, so, if I make a checkout from another computer I get the recently added files, which is perfect, but at my folder /myrepo still is no file, all the new files that were added from my client are not visible there, I know they implement many algoritms to take the version control, my question is, should I be able to see all the new files added from /myrepo in my server, without need to make a checkout with a client or something like that??
I want to know where my files are saved at my server,
Thanks
No. The files are stored in the repository you created, but in a specialized database. If you go to myrepo and look in the db folder, you'll see that there are revision files stored there. Those files contain the structure and data of the repository at specific instances in time. The Subversion book has some information on the structure. You can also look at the documentation in the actual Subversion repository about the structure used to store the data.
I'm using SVN externals to include a couple of directories from another repository but I also need to set up externals for two individual files in the root of the project directory.
According to the documentation this is not yet possible:
The URL for a file external must be in the same repository as the URL that
the file external will be inserted
into; inter-repository file externals
are not supported
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-externals.html
How can I work round this as I need two files to be pulled in from an external repository into the root of the project directory.
you could load them using a "folder external" and move the files either with a pre-build script or maybe a tortoise svn client hook (post-update). not a great solution, but maybe good enough for you?
Had to relocated our SVN repository, I edited the ccNet.config removed our state files and the old build directories. My build will start and pulls down the project for SVN but right after getting my project from SVN the build hangs and the .sln file gets deleted. Any Ideas?
From the question it is not really clear what you mean by build. I understood it is the complete CruiseControl build process [Event -> Checkout/Update -> Compilation -> Tests], not the compilation.
I would check these in order:
Did you relocate the local copies used by CruiseControl.NET?
Check the SVN URL path associated with the working copy, and its revision, did it really update to what you expect?
Check the credentials, do you provide them in the CC config or do you rely on the SVN client credential cache. This might have to be updated.
Activate Debugging in the CCnet config and have a deeper look at the log file.
What sounds strange is why the .sln file would be deleted, was it really in the repository or only created in the past because you opened a project file? A reason could be an uncommitted SVN delete made by mistake. A revert on the local copy can help in this case.
Jdehaan, your answer was very helpful. We had a couple projects on the build server pointed to the old repository that needed to be relocated.