I'm using perforce, and I have a ../dev folder with my code, a ../trunk folder with the testable code, and a ../rel folder for the code ready to be deployed to production. The way I work is that I work on ../dev, and when I have a stable version, I branch to ../trunk. After testing, I grab ../trunk and branch it to ../rel.
I accidentally branched ../dev to ../rel, so I went ahead and marked for delete the ../rel folder. Then, I tried to branch ../trunk to ../rel but perforce is failing saying that "Can't populate target path when files already exist". So, it seems that even if I delete the files that were wrongfully on branched to ../rel, they still exist and I can't overwrite them with the ../trunk files.
What can I do?
Use the "force integration" flag:
p4 integrate -f ../dev/... ../rel/...
Related
I forgot to commit on the directory where I was working and then I checkout to the previous commit and now I want to back to the directory where I used to work. What can i do ?
If your checkout of the previous version somehow deleted your folder, which was not added/committed, then you would need to rely on a file recovery utility, as detailed in "Can I restore deleted files (undo a git clean -fdx)?", or on your IDE. Some of them keep a local history (IntelliJ IDEA, VSCode through an extension, ...): you might get back some of your files content that way.
In the end, it depends on the exact git checkout command you did, considering this command can update files and/or branches.
That is why it is recommanded to use git switch (branch only) or git restore (files only), instead of git checkout.
I reinstalled my OS (KDE neon) and I thought why not backup my project git folder, before I reinstalled I made sure I commited any code and everything in my git project folder was up-to-date.
So after reinstalling, I moved my project back onto my PC from my backup drive and ran git-status and it wants to stage nearly all of my project?
What do I do? I don't want to commit all these files again when I have not editing any of them? Its nearly 800 files it wants to stage?
You could reset your project using:
git reset --hard branch_name
This would lose any unstaged files.
Or you could stash the changes:
git stash save 'msg'
This works like the previous one, but instead it saves the unstaged files in a separate "memory" (in case you need them later on).
Now, I may assume that the reason you got that situation in the first place is maybe when you restored your data back from the drive, the OS changed some properties on those files, stuff like creation/modification dates, permissions...etc. While the content of the files has not changed but the properties are. Still, git sees them as modified files.
I have a linux eclipse project checked into our company svn. Works great.
The project is intended to be cross compiled on Windows.
Untill now, I have simply moved the source files between OSes. However, I thought I'd like to let svn do this for me. Should be simple enough, just checkout the eclipse linux src into the VS project dir, right? Wrong!
The correct source was checked out of svn and it worked fine. But when I tried to check it back in i kept getting "Commit not completed filename remains in conflict" errors. I hadn't even changed anything!
Did a little checking. Turns out the linux src directory is pretty much just the source and headers. On the MSVS side the project directory contains the source and headers but also contains a bunch of files that are used by VS with names like projname.vcproj etc. etc.
So, I did a checkout into a scratch dirextory, .\fred. Checked .\fred back in. No problems. Added a new file to .fred, xxx.xxx. Check in reported:
svn: E200009: Commit failed (details follow):
svn: E200009: 'C:\Projects\fred\xxx.xxx' is not under version control
Makes me wonder about those uncommitted Visual Studio files.
So, are those files my problem? Are they breaking the commit operation?
As an alternate solution I am thinking of adding the VS files to the src dir in svn. If linux/eclipse checks them out I can tell eclipse to ignore them (I think it'll just ignore them for me). Any thoughts or recommendations for this approach?
(BTW, i still had fresh source on the linux side so any thing that got clobbered could be safely restored.)
So here is one solution I have working for the moment. I am not sure how totally stable it is.
Caveat: The project i am using already existed as a MSVS project.
In the MSVS solution dir, rename the source dir (MSVS likes the source dir name to match the solution dir name, so this means the source dir may not be named src) to something uninvolved in the solution, like temp.
SVN checkout the src (eclipse like to call source dirs src).
cd into the source dir. Issue the command:
svn changelist msvs *.cpp *.h
Add *.c if needed. "msvs" is the changelist name. It can be whatever you want ti to be.
This will created a changelist for the checked out directory.
Now, copy the remaining files from the temp directory into your source dir.
When you need to do a checkin, cd into the source dir and issue this command:
svn ci --changelist msvs
Note. You have to be in the src dir for this to work.
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working
When I trying to commit I get this error. What that was done, I think is a rename of the folder. I tried already rename / move the folder. But I continue to get the error.
Command: Commit
Error: Commit failed (details follow):
Error: File 'Page.aspx' is out of date
Error: File not found: transaction '99-4a', path '/trunk/src/Solution.UI/Views/ViewName/Page.aspx'
Error: You have to update your working copy first.
I do try to update, but unfortunately is doesn't solved the problem.
Command: Update
Completed: At revision: 99
Edit: after the deleted the files from the folder, do update to restore them, and replace the restored files with the originals I get this error:
Error: Commit failed (details follow):
Error: Base checksum mismatch on '/trunk/src/Solution.UI/Views/ViewName/Page.aspx':
Error: expected: ed3bc4a70ee4256bd2f7cf8c57f29a1f
Error: actual: b8a2797dc262dc714fae6dc897b5ebd2
SVN knows that there was a change in the repository, but it does not know what that changes was. You might have made exactly the same change on your working copy, but unless you actually try to do update so that SVN can run the resolve, it won't check that your local change is the same as the repo change.
Do an svn update and the conflict resolution should be automatic. Though, if you've made changes to the same files, it might ask you to manually resolve even if it's exactly the same change (Even more likely if the change was a folder rename)
You might have to do also an svn resolved to enforce the manual conflict resolution.
Worst come to worst, you can always copy the files you've changed, revert local changes, update and replace the files in the new folder.
I'm using TortiseSVN, and encountered the problem you're having.
Attempted effort: Delete a directory and the files in it.
My resolution path (entire effective procedure)
Select relevant files. Right-click | TortiseSVN | Delete
Response: Files marked for deletion.
Right-click on containing directory | TortiseSVN | Commit
Response: Files Deleted.
Right-click on the next-higher directory from the aforementioned containing directory | SVN Update
Response: Update complete.
Right-click on the directory I wish to delete | TortiseSVN | Delete
Response: Directory marked for deletion.
Right-click on the next-higher directory from the aforementioned directory-to-delete | SVN Commit
Response: Directory Deleted
Process Complete.
Do an "SVN Cleanup", then do an update
It looks like you have Page.asx in you working copy and it doesn't exist in repository anymore?
maybe try deleting it physically from your drive or if it's still needed just move it away to different location, try commiting and then add it again?
Sometimes you can get these strange broken working copy issues and despite trying everything, you can't get it to work again and you're completely unable to commit your work. One way to get out of this situation is to do the following:
Check out your project to a new folder.
Copy the modified files only from your old working copy to your new working copy. If you commit often this shouldn't take long. If you commit once a month, this could take some time...
Double check that the modifications list is the same on both working copies.
Commit from your new working copy.
Delete your old working copy and check it out again.
It's not very satisfying to do it this way as it doesn't show you what went wrong and why, but if you just want to get on with your work, then it's nice to know that there's a quick fix.
You have to update your working copy.
That is, perform an "SVN Update" in order to get the latest revision, and check to make sure your changes don't conflict.
I tried this solution and it works perfect for me .
1-Export the working copy to another Temp directory .
2-Delete all the files in your working directory
3-Check out in the working directory
4-copy the Files in the Temp directory to the working directory overwriting all existing files
5- Commit
You should just uncheck deleted or missing files when doing svn commit