Today I was trying to integrate from a child streamC to a parent streamP (copy-up operation) in Perforce. This operation is performed almost every day and usually we don't experience any issues. But today something went wrong. On a few files Perforce throws an error:
Operation 'rmt-FileFetch' failed.
Librarian checkout /opt/perforce/..../fileA
Error opening librarian file /opt/perforce/..../fileA revision 1.2555519.
RCS checkout 1.2555519 failed!
RCS no such revision 1.2555519!
And the same error is shown on a few other files.
I've checked status of these files in a parent stream streamP and they are all marked for delete by somebody else.
Is it a bug in perforce that you cannot integrate file deletion if it is already marked for delete?
Or is it a perforce infrastructure issue and I need to talk to IT guys?
If the file is deleted in the source there shouldn't be a librarian operation at all. Sounds a lot like this (fixed) bug:
Bugs fixed in 2016.1
#1378013 (Bug #85458) **
'p4 copy' could produce a librarian error when attempting to copy
a source file that was moved and then deleted. Fixed.
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
Related
I have recently started using Mercurial and in the extensions list provided by TortoiseHg Workbench I found an extension called Simplelock. I am unsure on how to use this. As in I find it necessary for my project but I am unable to use this since whenever I try to click Lock Repository it gives me the error: Operation aborted: No lock repository configured.
This is probably my in-expertise talking but would someone tell me how to work around this and to use this?
Thanks!!
Have you configured the lock repository?
Initialize an empty repo where everyone on your team can access it. Everyone should clone the lock repo locally and configure their global hgrc or Mercurial.ini file with the location of the lock repo.
[simplelock]
repo = ~/work/locks
I am using windows explorer to clone a repository from a folder in a mapped drive into my local working folder. I have never encountered this problem before with any of my previous repositories, but I keep getting an error while the directory is cloned. The error points to a file that is of "unkown format". This is the exact error:
abort: index data/Scripts/tiny_mce/themes/advanced/skins/default/dialog.css.i unknown format 5661!
About half of the repository gets cloned, but it never finishes because of that error half way through. I have used a remote command that supposedly skips over unknown formats (I found it somewhere online), but it doesn't work. This would be the complete command:
hg clone --remotecmd skip-unknown-format --verbose -- Q:\mercurial-repository\east C:\working
Any pointers on how I can skip that one file and/or how I can fix this error?
This is my hg version info:
version 2.4
with Mercurial-2.2.1, Python-2.6.6, PyQt-4.8.6, Qt-4.7.4
Trying to configure Jenkins CI. Currently just running it from the .war (eventual intention as a service). Jenkins is aware of the CVS executable (i.e. will read the version [Concurrent Versions System (CVSNT) 2.0.62.1817 (client/server)]).
The .cvspass is not specified, because they apparently do not play nice with CVSNT (which prefers to keep passwords in the registry.) I've specified the password in the job config by using the :pserver:user:passg#server:/dir pattern for CVSROOT, which I found suggested in some places. Regardless of whether I run using that, or :pserver:userg#server:/dir as the CVSROOT I get the blinking red ball, jenkins stuck with a nearly full progress bar for 2 and a half minutes. It then fails. The console output yells with something like
FATAL: hudson.scm.ChangeLogSet.iterator()Ljava/util/Iterator;
java.lang.AbstractMethodError: hudson.scm.ChangeLogSet.iterator()Ljava/util/Iterator;
at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:282)
at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:279)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:596)
at hudson.model.Run.run(Run.java:1400)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)
Both CVSROOTs I'm using provide no trouble with TortoiseSVN. I've found some mention of difficult of logging into SVN from jenkins as a service and related user/system issues, but considering I'm running it from the .war I don't think that's the issue.
EDIT:
Interestingly the console log if I use an invalid user or password recognizes such.
cvs [checkout aborted]: authorization failed: server rejected access to /dir for user FOO
FATAL: CVS failed. exit code=1
Finished: FAILURE
which indicates that Hudson is talking to the CVS server and authenticating, but something else goes wrong.
/EDIT
Cheers
Answer to the question found, thanks to rpetti on #jenkins on freenode. Problem was I had switched between Hudson and Jenkins and there were some incompatible configuration files that were mucking things up. Deleting and recreating the home directory solved the problem.
CVSNT 2.0.62.1817 is very very old and has several known security issues. Please upgrade to the latest 2.8.01.
In the job configuration for a Jenkins 1.418 job (older versions are Hudson) on Windows, I am having trouble with "Archive the artifacts". In the box titled "Files to archive" I have
foo/**/Release/Install/App.exe
The error it gives me at configuration time is:
'foo//Release/Install/App.exe' doesn't match anything: 'foo' exists but not 'foo//Release/Install/App.exe'
Now, if I'm correct, ** is "search all subdirectories" as per ant. What is odd, is that no matter what I enter it tells me the top level folder exists (foo), but no other folder exists underneath it. Yet when I use the windows explorer to navigate, all my folders exist.
How can I troubleshoot this or fix it?
Update: I figured out a technique to troubleshoot - use the workspace browse features in hudson/jenkins to find what is visible and what is not visible. Turns out some directories had file permissions that blocked them being visible inside jenkins/hudson.
I had hudson configured to run a batch file, and my folder references were failing because of some errors in the batch files I was using. This was not a hudson problem, but a batch file problem. I saw the error and thought it was the problem because it was a reported error, but the real problem was a silent failure in a batch file.
I'm trying to use the SVN Publisher plugin to commit some artifacts of my build but I'm getting a non-sensical error:
workspace: /Users/builder/hudson/workspace/myproject/
Attempting to import to SVN: https://mysvnrepo.com/svn/myproject/_SNAPSHOT_
SVN Publisher: target: /Users/builder/hudson/workspace/myproject/myproject/_build
SVN Publisher: Error: target Directory not accessable: /Users/builder/hudson/workspace/myproject/myproject/_build
This path is readable by the user that the hudson slave is using.
In looking at the comments on the SVN Publisher page, it seems that some people have run across this problem while others have not.
My question is: for those of you that have gotten it to work, what did you do?
It seems that the plugin is running on the hudson server even though the build is using slaves. This seems to be a bug in the SVN Publisher plugin. :(
It looks like you should be able to utilize the "Copy files back to the job's workspace on the master node" to get these files back to the server (this part works for me). It appears to happen after SVN Publisher is run, but that would be OK and simply means that SVN publisher should be committing (or importing) the previous build. But alas, SVN publisher doesn't seem to be doing anything except logging a message.