I'm using bitnami gitlab stack on Vmware Vsphere ESXi 5.5, I have accidently deleted ibdata1 and mysql restarted. I don't have any backup, Only i can go to last Snapshop.
I need help to know is possible restore current repositories files with copy on last snapshot files?
The repositories are saved in repos_path defined in gitlab.yml. You can backup the repositories, and then reinstall GitLab from scratch.
GitLab has a import script to import existing repositories to GitLab. You can run the script, to get the projects recreated. Since you deleted the database, all existing events, comments, issues are lost!
Related
I have a feed configured in Azure DevOps, with an upstream feed of https://registry.npmjs.org.
When I run yarn from my terminal, all of the packages in my package.json and their dependencies are correctly downloaded to my machine, but only a subset are added to my feed (59 packages listed in the feed vs. 1029 in my node_modules folder). There are 17 packages explicitly listed in my package.json.
I need to have all of the packages/dependencies stored in the DevOps feed so that we can restrict allowable packages and versions. We want to prevent regular developers from adding new packages or changing package versions on a project - letting them just pick from the "approved" packages/versions (which we do by requiring them to use a different feed which is configured with only our "restricted" feed as its upstream source). If there's another way to do this, that's fine.
Once you consume a package from an upstream source once, a copy of it is always saved in your feed.
This may be caused by the cache, If the package is already cached locally. It will not download again and save the package in your feed.
Please run the command npm cache verify, you can see the package path along with other details. Clean the package cache and try it again, it should save all packages downloaded from the upstream feed.
In addition, please also try to run the project via hosted agent. With Microsoft-hosted agents, each time you run a pipeline, you get a fresh virtual machine.
I hope it can help you.
I have been looking for a solution to my SVN problem but have not yet found one. We have been using svn for a number of years without problems but I have been unsuccessful adding a new project as of late.
SVN is installed on a central computer we use as a server running Windows 7. We have TortoiseSVN installed on our clients and on the server. To create new projects in the past we would log onto the server and execute svnadmin create [drive]:/archive/new project. We would then create the trunk, tags, and branches folders using the repo-browser. Once that was done we could use TortoiseSVN to import the code on our local machines to create the archive.
Now when I create a new project archive the client computers return the error: "Could not open the requested SVN filesystem". The repo-browser says the same thing. I can perform all of the usual SVN activities from the client computers on all of the existing repositories, just not on any new ones. Also, if I use the repo-browser on the server it works.
What I have done so far is uninstall subversion and TortoiseSVN from the server and reinstalled TortoiseSVN 1.9.4 along with the command line tools and recreated the svn service. I also updated TortoiseSVN to 1.9.4 so there shouldn't be any version conflicts but it still does not work. Since everything works as long as I am on the server I suspect the problem lies in the network access configuration but I don't know what would be different from when it was working.
Also note that when I try to browse the archive with Firefox I can navigate down into the project trees of the older projects but not any new ones. Firefox displays:
<D:error>
<C:error/><m:human-readable errcode="160043">Could not open the requested SVN filesystem</m:human-readable>
</D:error>
Any help will be greatly appreciated.
PS: Access to the repositories on the server is through Apache 2.2
1. Using file-type access to repository over LAN is always The Bad Idea (tm)
2. Source of your problem (except the above) is changing format of repository-storage between version and inability of old versions read directly repositories of new versions: your client's SVN is older, than server-side (and worse - use|know only old format of repo)
Check version on client's hosts (I suppose, they are pre-1.6) and
update to version, compatible with server's version (1.7+ for 1.9.*)
OR
add any real network layer (svnserve is easy and lightweight choice) for accessing repositories (don't use file:/// anymore) - in this case old clients can communicate with fresh repositories
OR
run svnadmin create with additional option --compatible-version and correct version number as ARG
This is Permissions&Ownership Problem. User, under which Apache is running, now can't read filesystem-tree, created by user, used for remote login. Ask local admin "WTF?" and fix errors
How to overcome SVN — could not open the requested SVN file system
SVN Error: Could not open the requested SVN filesystem
Could not open the requested SVN filesystem on windows7 (start from answer HERE!!!)
We have a productive GitLab 6.8.1 running. I've set up a parallel VM with GitLab 7.10.4. Now I want to move all data from the old installation to the new one. I've already found a way how to move the bare repositories, but I have no clue how to import the user account information, issues, etc.
EDIT: The thing is further complicated by the fact that the original installation was built from source, was running on Debian, used MySQL as a database and the whole installation was pretty much messed up. That's why I didn't manage to migrate the old server and decided to set up a new one. The new server is an Ubuntu machine with GitLab installed from apt-get package (I think that's Omnibus, but I'm not sure what this means.) The new installation seems to use PostgreSQL.
FYI You haven't specified whether the old or new server is running a source installation or omnibus, or whether you're running a MySQL or Postgres database. Instructions differ depending on these factors, so please clarify and I will update my answer.
The first thing is that you will need your old and new servers to be on the same version of GitLab. You cannot migrate anything other than repos without having synchronized versions.
Depending on your reply to the above you will either follow instructions similar to the backup and restore tasks or by running the backup and restore tasks. Both options generally require you to manually copy configuration files or migrate settings from multiple files to a single new file (in the case of going from a source install to Omnibus). The Omnibus upgrade guide above lists the configuration files that need to be migrated depending on your environment.
Update based on edited question: There's a guide specifically for that scenario in this section of the Omnibus upgrade guide, using Option 2. You still need to have the same version on both old and new servers, though, I believe.
I imported Apache Nutch source code into my local ubuntu installation. I have subversion installed on my eclipse kepler. The sourcecode has several branches and one main project in trunk. I was thinking of specifying this source-code location as my repo location to svn and check out & or commit changes based off of this. However SVN always seem to expect a remote repo location. Is there anyway I can make this dumping ground of apache nutch source code as my repo location for svn?
Thanks
DVCS systems may help, such as git, Hg, etc.
Subversion is a centerized version control system, all workspaces directly connect to center repository.
But DVCS have local repository, before you commit to remote repository, you need commit to local rep first.
I have a trac repository available on a local network and need to take a dump of the trac data to be able to access it out of that network.
Can anyone suggest a way to do it ?
I don't think there is a unified command to dump both the trac project and a possible attached svn repo, but for separate dumping, Trac has a hotcopy command and svn a dump command.
Trac Backup - The Trac project
svn dump manual
Good set of answers on serverfault for this topic - https://serverfault.com/questions/6147/how-do-i-backup-my-trac-instalations