I have this accurev issue where almost ALL source-controlled dirs under my workspace are shown as "external" eventhough they are not --accurev stat confirms the same externality. Accurev update has not solved the problem: just pulls down the entire source tree everytime, indicating that the existing file-structure is external to accurev. I have poked around accurev manauals but, have not seen anything specifics on what the problem(s) might be. Any help is appreciated.
In the past, when this has happened to me, deleting everything in the external view and repopulating the workspace fixed this problem.
I usually just delete from the GUI if possible. Then open a command prompt, browse to the root directory of the workspace in question and run:
accurev pop -R *
You may have had an "accurev update" fail for some reason, which has left the workspace out of sync. To find out if this was indeed the root cause, you can run "accurev show -fx wspaces" from a command prompt and compare the Target_trans and Trans values. If they are different, you have an inconsistent workspace.
To resolve this, you can run "accurev update -9" which will force the update level to the appropriate transaction. Subsequently you can delete all external files, as Josh indicated, and re-populate them. The command for this would be "accurev pop -R ."
Hope this helps...
I know this is an old question, but I just had this issue.
Updating my workspace with "Timestamp Optimization" unchecked resolved the problem.
Related
I've searched for a solution to my issue, but it's strange and I can't exactly figure out where it's going wrong.
I have a batch file that seems pretty straightforward. In a directory that has two files, it's supposed to delete one, copy the other, then rename it to what the file just deleted was named. Everything seems to work properly except for the renaming. It almost appears that the script runs twice, but I can't find any actual evidence of this. Please see below:
SET filepath="\\server-name\directory with a space\"
SET oldFile=filename.csv
SET curFile=filename_*.csv
REM ===Delete current filename.csv===
IF EXIST %filepath%%oldFile% DEL %filepath%%oldFile%
REM ===Copy all versions of .csv files that begin with filename_ to the Archive folder===
IF EXIST %filepath%%curFile% COPY /y %filepath%%curFile% %filepath%%Archive
REM ===Rename the .csv file beginning with filename_ to filename.csv===
IF EXIST %filepath%%curFile% RENAME %filepath%%curFile% %oldFile%
If I run this manually, it appears to work fine. However, when I let it be called from a Scheduled Task, it appears to run twice... that is, it deletes the filename.csv, copies the filename_*.csv to the correct place, but then seems to delete the second file rather than rename it.
As I said, I'm really unclear on what is actually being done. I've tried logging the results in an output file, but there isn't anything helpful within.
Can anyone see anything I'm missing?
Thanks in advance.
Examine
IF EXIST %filepath%%curFile% COPY /y %filepath%%curFile% %filepath%%Archive
Note that archive appears to have a leading % - is this meant to be a directory "archive" or is archive set to something you're not showing us and therefore it should be ...%filepath%%Archive%
The consequence of the (?missing/stray %) is that the file would be copied to a file named archive or to a directory named archive if that directory already exists.
Personally, I'd use
SET "filepath=\\server-name\directory with a space"
where the quotes delimit the string to be assigned (so no stray trailing spaces are assigned to the variable) and then construct the source/destination names using "%var1%\%var2%" which ensures no double-" appear and the directory is obvious (but this is a matter of style).
It is a best practice to quote paths. In this case, where a space is involved, it is a requirement. It is easier to omit quoting from the varaiable definition and provide them where needed when the variable is used.
SET filepath=\\server-name\sharename\directory with a space\
IF EXIST "%filepath%%oldFile%" DEL "%filepath%%oldFile%"
In my experience, it is best to leave the directory at the end of a path without the trailing backslash. Also, a UNC path should have a sharename.
SET "filepath=\\server-name\sharename\directory with a space"
IF EXIST "%filepath%\%oldFile%" (DEL "%filepath%\%oldFile%")
I've finally discovered the solution to this. Turns out there was a copy of the task running on an older server that our new environment had been migrated from. It was running at the exact same time as the one on the new server, which is why it would run perfectly fine any way I tried to run it before or after the time the task was set to run. Disabling the old version of the task resolved the issue.
Thank you to those who provided feedback and suggestions on my commands!
i am running a long matlab script and it should run when i am not around.
part of the script cleans up previous created folder structures (temp data).
rmdir('dir','s');
however matlabs rmdir will ask me the following:
remove entire contents of dir? (yes or now)
and i need to supply either yes or no to proceed.
i tried piping
pipe(printf('yes'),rmdir('dir','s'));
and other things but nothing works so far.
Problem
how do i autoconfirm with 'yes' to 'rmdir' so my script will not get stopped because of this issue?m
Using confirm_recursive_rmdir you can turn this question on or off. This is a feature of octave, matlab never asks to confirm rmdir
confirm_recursive_rmdir(0) will do the trick
My laptop crashed this morning after which the wampmanager.ini was corrupted. I found out how to resolve that by pasting in a replacement and ensuring that this line pointed to the correct directories:
Action: run; FileName: “c:/wamp/bin/php/php5.4.3/php-win.exe”;Parameters: “refresh.php”;WorkingDir: “c:/wamp/scripts”; Flags: waituntilterminated
However, I still get an error "Exception Eception in module wampmanager.exe at 000F15A0. Could not execute run action: The directory name is invalid.
I have check: “c:/wamp/bin/php/php5.4.3/php-win.exe” and “c:/wamp/scripts”. I even pasted them into the address line at the top of the page to make sure and they were found.
What are my options please?
Can I run a repair?
Is it just quicker to reinstall?
If I reinstall which directories do I need to copy in order to save my database?
I do not know much about this so if you can be specific please that would be very much appreciated (e.g., full file paths where possible).
Thanks,
Glyn
I have found this:
http://forum.wampserver.com/read.php?2,71125,printview,page=1
https://superuser.com/questions/373255/wamp-not-working-on-windows-7-64bit
Now I need to work out whether I am using WampServer 32 bit or 64 bit. How do I do this please?
You are nearly there, wampmanager.ini is recreated every time you run wamp. What you actually need is an uncorrupted wampmanager.tpl.
If you have a backup, replace the wampmanager.tpl file in \wamp
SECOND ANSWER:
You could try this.
Rename the old wamp folder.
Install WAMP again, using the same version of wamp Apache,MySQL.
Copy your database's from old location to new location + any website code.
That should get you back to where you were roughly.
In my case it happenned because I moved by mistake folder "scripts" from "C:\wamp" to "C:\wamp\tmp". I put it back and it works now.
I found this soltion looking in "wampmanager.ini" (section [StartupAction]) the directories expected to find, and I saw that "scripts" was missing.
I am porting over an MSBuild script from CCnet to run in Jenkins. The MSBuild project is used to create a deployment package. I would rather have Jenkins drive this process itself but that's a longer term aim.
The problem i am having is (as in the title) when we try and use the HgPull target, from the MSBuild mecurial task (http://msbuildhg.codeplex.com/) we get the error message
HgProcessException: The command hg.exe is not available [Path to project]
I have seen on the project web site that someone solved it by adding the LibraryLocation proeprty to the target but that seems to have made no difference. My target currently looks like this:
Target Name="UpdateSources">
<HgPull
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Force="true"
Update="true"
LocalPath="$(SourcePath)"
/>
<HgUpdate
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Clean="true"
LocalPath="$(SourcePath)"
/>
I'm rather at a loss. Please let me know if you need any more information added to this post to solve this issue. I'm really quite new to MSBuild so really not sure where to start investigating this.
EDIT:
One thing i forgot to mention was that i have tried running the MSbuild command in a console window on the build server and still get the same result. This is really odd given it works fine in CCNet, what magic is CCNet doing to make this command work?
This is now resolved, unfortunately i'm not sure what changes i made to correct these. I believe it may have been down to path separators and whether they where trailing or not in another part of the config file. It does so annoy me with the lack of resilience/consistency between applications where you need to specify paths with/without trailing slashes.
Just a thought, but try adding 'C:\Program Files\TortoiseHg' to your system path. Maybe CCNet has it specified somewhere that Jenkins doesn't have access to.
Also, just for sanity's sake, verify that hg.exe actually exists at that location.
When I create a new repository, I can ask TortoiseHG to give me a .hgignore file. Is there a way that I can customise what that file will look like, rather than having to go and get one manually from somewhere every time?
It's an old question, put still popped up as the first result on google, so here is an update:
In the TortoiseHg settings under the tab TortoiseHg users can specify the path of a Repo Skeleton. You can put your predefined .hgignore there, and it will be automatically copied during hg init.
See also:
#3569 Allow user-defined default .hgignore file when creating a new repository
TortoiseHG Docs
Like Tim already said in his comment, apparently it's not possible to do this.
Take a look at the following issue from TortoiseHG's bug tracker:
#966 Include some reasonable defaults in .hgignore on repo creation
Quotes from this link, both by Steve Borho (THG project lead):
This topic comes up on the Mercurial mailing list once a year or so and Matt always shoots it down. There is already support for user level ignore files; one could add these globs to a global file and be done with it.
and:
If a user has files or directories that they always want to ignore, they can add those to a global ignore file without having to introduce any new behaviors in THG.
So putting the things you always want ignored in a user-global ignore file seems to be the only option (even though it's not exactly what you're asking for):
Would like to create some defaults for my .hgignore files in TortoiseHG/Mercurial
(the question that I posted in my comment above)
Global hgignore usage