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.
Related
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 am new to perforce. I need clarification on the below.
I have created workspace and by mistake i have checked out the entire project(all files). I have not done any changes in the local workspace. After some days i tried to get latest revision from the server it shows some merger conflict error.
Now, How can i release the checked out files without affecting remote files. Will it affect remote files if i do revert operation locally.
Thanks for your kind advice.
Selva
If you haven't made any changes then simply reverting the checkout will "release the checked out files". This will not affect any files checked out or modified elsewhere as it is simply an operation that works on your copies of the files.
Any operation you can do will only affect your local copies and the files in the depot. You cannot directly affect files on other people's machines.
I am wondering what happens in SVN when a file is updated directly instead of using SVN? The main reason I am asking is that there was a problem updating the SVN on my machine (windows) when the server (linux) had 2 names that were the same, but different case. I resolved this on the server, but didn't do it through SVN since it won't update correct, but I still get the issue. Do I need to run some kind of command to update it?
Thanks.
EDIT:
I deleted the comflicting file in the working direcotry and wanted to know if doing things directory in the working directory get tracked at all or what needs to be done to resync.
When SVN gets blocked because the repository is more "up to date" than the local checkout, one brain dead foolproof solution is:
Move (or remove) the files that are causing the conflict at the command line (don't use SVN tools to do this, and don't use the GUI if you have tortoise installed).
svn update the repository, which will restore the current copy of the files from the subversion server.
Decide what to do with your cached copies of the old files. Either manually merge them back into the repository, discard them, or remake the changes in the new svn managed files (depending on your needs).
Note that if you move the files into a directory using tortoise, make sure that you move it into a directory that's not associated with ANY SVN project. It's not fun trying to undo the helpful changes tortoise does in thinking your wanting a SVN move to accompany the file system move.
There is no need to run any special commands. If you updated the sources, the next time you will run svn update subversion will seamlessly merge the changes and you will get an uptodate working copy.
If you changed some files, they will appear modified or conflicted depending on the changes made by you and other users.
This has been plaguing me for a week.
SVN keeps telling me that a certain file "does not exist in repository".
Fine. Let's just delete it. Forget about it. Ignore it. Whatever. I don't really care about this file (especially if it continues to fail the nightly check-in).
The most bizarre part? A "restore" will actually RESTORE the file from the repository, so its there (corrupted, maybe?).
...and this has to be the icing on the cake. If I delete the file through Windows Explorer, SVN will RESTORE the file from the repository, and right after that state that it doesn't exist in the repository. WTF?
Does anyone have a clue how to get rid of this?
I've already tried clean-ups, reversions, deletions and anything else imaginable, but this one has me stumped.
Thanks for any tips you might have...
It seems most likely that you have corrupted your local working copy, e.g. by moving folders or some other manipulation that you did with windows explorer but should have done through the TortoiseSVN context menu. The information inside the .svn folders now no longer matches the state of the working copy, which is confusing Subversion.
To fix this, delete the parent folder ("Originals") in your working copy with windows explorer (NOT with TortoiseSVN). Then do a TortoiseSVN "update" at the root of your working copy. This should restore the folder in working order.
Another option is to discard your working copy entirely and do a fresh checkout.
Note that the next release of Subversion (1.7) will reduce the opportunities for corrupting your working copy by centralizing all metadata in a single .svn folder at the root.
I've had similar problems with corrupted working copies. Sometimes the working copies have a lot of pending changes but unable to checkin. To resolve this, I use the following approach (svn 1.7+):
Checkout a fresh working copy into a new directory (path2)
In the fresh working copy, if the offending file is there, delete it if needed.
Commit the fresh working copy
In the fresh working copy, delete everything except the .svn directory
Copy everything from the old working copy except the .svn directory into the fresh working copy.
Commit the fresh working copy again
Delete (or backup) the old working copy
Rename the fresh working to the old working copy (path2 to path)
I had faced a similar problem wherein i had a folder, for example "FolderA" which consistently shows in svn update even though I had deleted it.
It would not even show in the folder list but svn would still recognise it as if it exists.
I followed below steps:
1.Create same folder name for which svn was giving error in the same file location
2.Added it to svn checkout. Since it gave conflict errors, i resolved it using the svn option to resolve.
3.Deleted the folder and committed my svn.
Error was resolved
I cannot figure out why I get this error during check-in. I checked in successful only a few hours ago so not sure why now it's complaining
Error: Commit failed (details follow):
Error: Checksum mismatch for
Error: 'C:\sss\sss\trunk\xxxx\.svn\text-base\Header.ascx.svn-base'; expected:
Error: '3cee96f580409a1711a47541a07860dd', actual: 'a5fc0f8819b88bf32ab38d4c9a6b0654'
Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout.
I got latest and also performed a clean-up which said successful so not sure what else to do.
Something has gotten out of sync or has become corrupt, and because it's in your .svn BASE directory, unless you are confident tinkering with this, you're probably better off deleting the parent of the .svn directory and then perform an update. Of course, take a backup or see if an export works before doing this, so you don't lose any changes.
FWIW, I get this sometimes with our library references where Visual Studio seems to keep a lock on some files (even though it's not compiling) and won't let me update them. I believe this is related to the xml documentation files.
Note: Subversion 1.7+ implements a new working copy approach which centralises the meta data, and it now has a single .svn directory at the root of your working copy. Your best bet is a cleanup, failing that a fresh checkout into another directory and export or file copy the corrupted working copy except for the .svn directory, over to the fresh checkout, and commit any local changes.
Looks like one of your SVN files is corrupt. First, check-in everything that can safely be checked in, and make sure to backup everything. Then fix the offending file - usually this involves deleting it from your repository. This should be okay if you're checking in a new version anyway.
I received a similar error after our project repository was moved to a new server. Try reverting your file and reapplying your changes.
I had same problem after googling for some help found articles that suggested to override the checksum in the .svn\entries file. But in that file the checksum was actually as the the expected one in the error message.
To fix the problem, I navigated to .svn\text-base dir of problem file's directory and found out that there's a copy of the file i was trying to check in changes for. I opened that file in Notepad++ and replaced it's content with content of the file to be commited and i was able to commit afterwards.
But just in case, make a backup copy of the .svn\text-base file.
I think this happened because i did an svn update before commit because it complained that my version is outdated. Anyway, it's fixed for me and hope my solution helps someone else too.
With Tortoise SVN, I choose to delete the file in Repo Browser.
First back up the problem file. and use Repo Browser delete the problem file in it, then update local folder so the file in local folder is deleted. Then copy back the backup file and Add > Commit, then I can update successfully.
The disadvantage of this method is the history of this file will be removed.
Also see another post.