Good afternoon,
Using version 2.4.0-dev on a Linux machine, I am trying to migrate a CVS project to SNV. I had some issues with symbols, and I created a hint rule file based on symbol-info.
Now to my current error. The CVS project is called package. I want to migrate it to SVN under the directory structure svnrepos/sw/package. The svnrepos/sw already exists (along with other projects under svnrepos.
In my option file (created from cvs2svn-example.options), I am using
ctx.output_option = ExistingRepositoryOutputOption(
r'/var/svn-test', # Path to repository
#author_transforms=author_transforms,
)
...
run_options.add_project(
r'cvs/package',
trunk_path='sw/package/trunk',
branches_path='sw/package/branches',
tags_path='sw/package/tags',
...
I also tried
run_options.add_project(
r'cvs/package',
trunk_path='trunk',
branches_path='branches',
tags_path='tags',
initial_directories=[
r'sw/package'
],
with the same error:
----- pass 16 (OutputPass) ----- Starting Subversion Repository. Starting Subversion r1 / 635 Starting Subversion r2 / 635 Starting
Subversion r3 / 635 ERROR: svnadmin failed with the following output
while loading the dumpfile: svnadmin: E160020: File already exists:
filesystem '/var/svn-test/db', transaction '48-1c', path 'sw'
I am at a lost on how to resolve this issue.
Note:
My initial tests were using command line arguments with the results that trunk, branches and tags were created in svnrepos/trunk, svnrepos/branches and svnrepos/tags respectively. As I indicated earlier, I want these to be under svnrepos/sw/package
Thanks in advance
Daniel
I solved this issue. Essentially the migration has to be done is two steps
1.Use cvs2svn to produce a dump file. In the option file, I used the following
# Use this type of output option if you want the output of the
# conversion to be written to a SVN dumpfile instead of committing
# them into an actual repository. The author_transforms option is as
# described above:
ctx.output_option = DumpfileOutputOption(
# dumpfile_path=r'/path/to/cvs2svn-dump', # Name of dumpfile to create
dumpfile_path='packageDump',
#author_transforms=author_transforms,
)
Note that the path for trunk, tags, and branches also includes a reference to package.
run_options.add_project(
r'cvs/package',
trunk_path='package/trunk',
branches_path='package/branches',
tags_path='package/tags',
As I mentioned in the original message, there were some symbol issues, and I created a symbol hint file where svn-path points to my desired package directory. For example
0 tag_pk_1_0_0 tag package/tags/pk_1_0_0 .trunk.
2: Use svnadmin load to load the generated dumpfile onto svn
svnadmin load --parent-dir sw /var/svn-test < packageDump
Related
There is Prometheus Oracle database exporter https://github.com/iamseth/oracledb_exporter
Under Running section, "/path/to/binary -l log.level error -l web.listen-address 9161" is not clear me.
Here I am not getting what is "/path/to/binary" mean, is it oracle client or /usr/bin/ path, or which file I need to replace with? I have RHEL7.3
After setting DATA_SOURCE_NAME is set correctly and running below commman, its throwing error (no such cmd - /path/to/binary)
/path/to/binary -l log.level error -l web.listen-address 9161
Please refer ZIP/clone from location :-https://github.com/iamseth/oracledb_exporter
Oracle database exporter should start and fetch required values/status from oracle database.
In case you're still looking for the answer:
The easiest way is to download the pre-compiled version. Otherwise you will need to compile it yourself: https://github.com/iamseth/oracledb_exporter/releases
Download the version you want e.g. 'oracledb_exporter.0.2.2.linux-amd64.tar.gz' and unzip it.
You will get a folder 'oracledb_exporter.0.2.2.linux-amd64' which conatins two files:
default-metrics.toml
oracledb_exporter
The second one is the one you need to execute:
-> /path_to/oracledb_exporter.0.2.2.linux-amd64/oracledb_exporter log.level error web.listen-address 9161
I am trying to modify one of the CentOS (7.6) kernel source file and recompile all of them for later installation.
I followed the guide on wiki.centos to do customized kernel:
https://wiki.centos.org/HowTos/Custom_Kernel
I found that in step 5, the RPM method always unpacked source files from tar files and replaced my modification in BUILD/.
Therefore, I changed my way. I put my modification at another place and added a line in kernel.spec file under SPECS/ to copy my file into the BUILD/. Namely, one-line with cp command is put before %build in the kernel.spec (after unpacked). However, the compilation went wrong in the %build section:
...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.Vd6by5
BUILDING A KERNEL FOR x86_64...
USING ARCH=x86_64
...
###
### Now generating an X.509 key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the
### background to keep the supply of entropy topped up. It
### needs to be run as root, and uses a hardware random
### number generator if one is available.
###
Generating a 3072 bit RSA private key
....++
......................................................................................................................................................................................++
writing new private key to 'signing_key.priv'
-----
###
### Key pair generated.
###
- Including cert /home/user/rpmbuild/BUILD/kernel-3.10.0-957.12.2.el7/linux-3.10.0-957.12.2.el7.v2.x86_64/centos-kpatch.x509
- Including cert /home/user/rpmbuild/BUILD/kernel-3.10.0-957.12.2.el7/linux-3.10.0-957.12.2.el7.v2.x86_64/centos-ldup.x509
- Including cert signing_key.x509
RPM build errors:
Could somebody suggest me a better way to replace the source file in the compilation procedure?
Thanks.
I found the solution myself. Instead of directly replacing files, we should apply patch within RPM to indicate the differences between modified file and original file.
Firstly, use diff command to build patch. Then, modify spec file, kernel.spec, applying the patch to the building procedure.
This website shows the example when using this way to compile kernel:
https://www.hiroom2.com/2016/05/29/centos-7-rebuild-kernel-with-src-rpm/
A more clear reference for patching files:
https://rpm-packaging-guide.github.io/#patching-software
I am creating setup of large data approximetly 10 GB with NSIS Script and trying to create a single setup (exe). Its giving an Error -
Internal compiler error #12345: error mmapping file (xxxxxxxxxx, xxxxxxxx) is out of range.
Note: you may have one or two (large) stale temporary file(s) left in your temporary directory (Generally this only happens on Windows 9x).
Please tell me how to solve this issue ?
Is there any other way to create a setup for this kinda situation ?
NSIS installers are limited to 2Gb.
If you absolutely need it to be one file and you want to continue to use NSIS you have to append the data to the end of the generated setup. I'm not sure I would recommend that approach but it could work if the appended data is a zip file (or some other format with the header at the end) and you use one of the NSIS zip plugins to extract at run-time...
I have used https://sourceforge.net/projects/nsisbi/ instead of normal NSIS. It solved the problem.
I was using Silent Install Builder 5 and received this same error with a package installer that had LESS that 2 GB total. Once I determined that the NSIS compiler was to blame, I began experimenting with several possible solutions and here's what worked: I downloaded the newer NSISBI compiler from here https://sourceforge.net/projects/nsisbi/ and then did these 3 steps:
Go to C:\Program Files (x86)\Silent Install Builder 5 and renamed the default NSIS folder to a new name.
Copied the NSISBI folder into the C:\Program Files (x86)\Silent Install Builder 5 directory and renamed IT to NSIS.
Tries to compile some large packages above and just below 2GB and the first few tries I would get missing file errors in the Silent Install Builder 5 compiling box. No worries because the missing files are in the old NSIS folder, that's why y9u don't delete it.
Each time find the missing file error displays, find the missing files and copy them into the same folder location in the new NSIS folder. About 3 times you will do this until there are no more errors at all and you can then include the large files without generating the "internal compiler error #12345: error mmapping file xxxx is out of range." error message. NSISBI works!
I'm woking with a team mate programming something in parallel with another group in the same solution.
But, my mate has a different version, the most recent, that is different from my own, older one. I would like to know if there's any way to know the exactly source version that I have on my machine, and then tell him to get the same change sets from the TFS Server.
Is this possible? There's any place that log this kind of information?
To see what versions you each have:
In Team Explorer / Source Code Explorer, you may right-click on a file and View History to see all change set history, and you may right-click on a file and select /advanced/Properties to see what you have in your workspace.
The corresponding command-line comands are tf history yourFileSpec see tf history on MSDN and tf properties yourFileSpec see tf properties on MSDN
To get a specific version:
You may right-click on a file in Source Control Explorer and get specific version. This also has a corresponding command-line of tf get [itemspec] [/version:versionspec] see tf get on MSDN
The tf info command will tell you the details of a file. Included in this information will be the local version (the changeset that you have locally) and the server version (the latest version on the server.)
C:\Temp>tf info filename.txt
Local information:
Local path : C:\Temp\filename.txt
Server path: $/Project/filename.txt
Changeset : 1099
Change : none
Type : file
Server information:
Server path : $/Project/filename.txt
Changeset : 1099
Deletion ID : 0
Lock : none
Lock owner :
Last modified: Thursday, May 26, 2011 10:04:49 PM
Type : file
File type : Windows-1252
Size : 619
My VS2010 database deploy is failing on my build server, which has SQL Server 2008 R2 installed on it. Here's the output that's relevant:
Creating Acme.Database...
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 5133, Level 16, State 1, Line 1 Directory lookup for the file "C:\Program Files\Microsoft SQL Server**MSSQL10.MSSQLSERVER**\MSSQL\DATA\Acme_Database_log.ldf" failed with the operating system error 3(The system cannot find the path specified.).
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 1802, Level 16, State 1, Line 1 CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
An error occurred while the batch was being executed.
The actual path is here:
C:\Program Files\Microsoft SQL Server**MSSQL10_50.MSSQLSERVER**\MSSQL\DATA\Acme_Database.mdf
The only reference to the path I could find in the database project was in the root folder, a file called:
PRIMARY.Acme_Database.sqlfile.sql
It includes an ALTER DATABASE statement that I changed to use the _50 path, but this did not fix the issue.
I'm not sure why the db project needs to know where the actual database MDF file is located in any case - I would have thought it could just connect to it vis TSQL, but in any case I can't get the project to deploy with this error and would appreciate any help.
Turns out if you specify a "file" in Schema Objects\Database Level Objects\Storage\Files (use Add Item, File) the values specified in the path override those looked up from the Server. If you must specify them use the variables from sqlcmdvariables $(DefaultdataPath)$(Databasename) to fill things out.
Take a look at the default file path on the server itself.
Screencast: http://screencast.com/t/OWM5ODFjZj
The fact that you don't have a path specified could likely be the issue.
[Update]
The reason I suggest this is that during the creation of the deployment script, if you have not specified the settings in the Project Settings -> Deployment tab, the DefaultDataPath is looked up from the target server's path.
I don't know anything about TeamCity really so this may be a stupid question, but how are you doing the deployment? It looks like the MSBuild deploy task for a DB project can take a property that gives the data path:
http://www.codewrecks.com/blog/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
Can you set the path that way?
I had the same error, but a different solution.
For me everything was correct (as far as I can tell), but the generated deploy script set the path variables before the databasename variable - resulting in a reference to a variable that did not exist. I updated Database.sqlcmdvars to hardcode the database name value - not best practice, but a sufficient workaround for my needs.