I am using SVN update to update my web directory on my linux server. when I do an sudo svn update it says theres a conflict. i choose the accept theirs full option which Im assuming it should pull the full repo file but it never seems to replace the file. SVN reports update status G but the file remains the same.
what is going on, how do i get the depot version. This is on a server so there should never be a modified file or conflict to begin with.
Revert all local modifications (and conflicts) after update:
svn revert -R <path>
Be careful, it wipe all your local changes
It turns out what I was doing was correct, but their was an old cron job I wasn't aware of that was updating the file on the server outside of SVN. So everytime I committed a change it was overwritten by a cron job kicking off an rsynch.
Related
It's been 14 years since I last worked with svn and appearently I have forgotten everything...
I have an existing web-project, consisting of a bunch of php, html, js and other files in a directory tree on a V-Server. Now I want to take these folders under version control and create a copy on my local machine using svn. So I installed subversion according to these instructions: https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/
Using the already-present apache2.
But now I kinda hit a roadblock. If I try svnadmin create on the existing folder, it tells me that is is not empty and does nothing really. All the questions and answers I find here and elsewhere are either
a) focussing on an already existing folder on the local machine
b) assuming more prior knowledge than I have right now aka I don't understand them.
Is there a step-by-step guide for dummies anywhere on how to do this? Or can anyone tell me in laymans terms how to do this?
I can't believe this case never comes up or that it is really very complicated.
At the risk of failing to understand your exact needs, I think you can proceed as follows. I'll use this terms:
Code: it's the unversioned directory at V-Server where you currently have the bunch of php, html, js and other files
Repository: it's the first "special" directory you need to create in order to store your Subversion history and potentially share it with others. There must be one and there can only be one.
Working copy: it's the second "special" directory you need to create in order to work with your php, html, js... files once they are versioned and it'll be linked to a given path and revision of your repository. At a given time there can be zero, one or many of them.
Your code can become a working copy or not, that's up to you, but it can never become a repository:
$ svnadmin create /path/to/code
svnadmin: E200011: Repository creation failed
svnadmin: E200011: Could not create top-level directory
svnadmin: E200011: '/path/to/code' exists and is non-empty
Your repository requires an empty folder but it can be located anywhere you like, as long as you have access to it from the machine you're going to use in your daily work. Access means it's located in your PC (thus you use the file: protocol) or it's reachable through a server you've installed and configured (svn:, http: or https:).
$ svnadmin create /path/to/repo
$ 😎
Your working copies can be created wherever you need to work with your IDE. It can be an empty directory (the usual scenario) or a non-empty one. The checkout command retrieves your files from the repo and puts them in the working copy so, at a later stage, you're able to run a commit command to submit your new and changed files to the repository. As you can figure out it isn't a good idea to create a working copy in random directories because incoming files will mix with existing files. There's however a special situation when it can make sense: when the repository location is new and is still empty. In that case you can choose between two approaches:
If you want code to become a working copy, you can check out right into in and then make an initial commit to upload all files:
$ svn checkout file://path/to/repo /path/to/code
Checked out revision 0.
$ svn add /path/to/code --force
A code/index.php
$ svn commit /path/to/code -m "Import existing codebase"
$ Adding /path/to/code/index.php
$ Transmitting file data .done
$ Committing transaction...
$ Committed revision 1.
If you don't care about code once it's stored in the repository or you want your working copy elsewhere, you can import your files from code and create a working copy in a fresh directory:
$ svn import /path/to/code file://path/to/repo -m "Import existing codebase"
Adding code/index.php
Committing transaction...
Committed revision 1.
$ svn checkout file://path/to/repo fresh
A fresh/index.php
Checked out revision 1.
So I had been (stupidly) making changes directly on the live server instead of making them on my local machine and deploying them. This messed up my deployment. So now I was to do "git reset --hard".
On my remote server I have a project.git directory (for the repository... which is bare btw) and a project directory (for my actual application).
But when I try to run "git reset --hard" it tells me I'm not on a working tree. If I go into config and change bare to false... it says the same thing.
Ideas?
Found a better solution. :)
First I did a git reset --hard on the local server (since the remote server is just a bare repository.)
Then I did a git commit -a which told me there were no changes but that there were untracked files.
So I did a git add . to add all the files that weren't being tracked.
Finally I ran git commit -a again and git push.
This updated my repository with all the new files and then cap deploy functioned as expected.
In Xcode we pulled someone else's push and merged with local copy. However now the pulled copy has corrupted storyboard. The worst thing is we accidentally pushed those corrupted file to remote repo. Now is there any way I can solve this issue?
we are using SourceTree as our interface to Git.
One of our member has the last working copy as we haven't pulled any corrupted data from server to his copy.
Any potential solution for this situation? Thanks
Sorry but I'm not enough of a Git expert be be able to give you the exact commands, but there are git commands you can enter to revert a file to a specific revision/commit. If you hunt around the web you should be able to find them and revert the file.
You may have to use command line Git.
This may help Reset or revert a specific file to a specific revision using Git?
and this Rollback file to much earlier version using Git
A pull and merge is commited to the history like any other change so you just need to undo that commit. The git command to delete the last commit and restore your working tree to the previous commit is:
git reset --hard HEAD~1
(from Delete commits from a branch in Git)
This change could then be pushed back up to your server.
I am a noob in these server related work. I am writing some PHP code in my local system and has been updating my repo in github regularly. Each time I want to test my application, I copy all the files from my local system onto my server through FTP and then do it. Now I want to know whether is there a way to automatically make the commits that I make to reflect in the files in the server. Is there a way to automatically make the server get the files from the repo periodically? (say, once everyday).
Can this be done other way, like when I make a push from my local machine, the repo gets updated and in turn the files on the server also get updated?
My Server Details: Apache 2.2.15, Architecture i686 with Linux Kernel 2.6.18-194.32.1.el5
In addition to cronjobs, you can use a post-receive hook: http://help.github.com/post-receive-hooks/
If you have cronjobs you can use them. First set up the repository on your server. Then you can set up the cronjob, choose a time in which it should be executed, and then in the cronjob execute the following command:
cd your/repository/folder; git pull master origin
Perhaps explore the git archive command, which you can use to get a zip file or similar of your code. You could then perhaps use a script to copy that to your (other) server?
git archive --format=zip --output=./src.zip HEAD
will create a zip file called src.zip from the HEAD of your repo
More info:
http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
Do a "git export" (like "svn export")?
I'm using git-svn. I've moved file 'A' to 'B' and I'm up to date with the svn HEAD (using git svn rebase). I can commit all other changes without problems. Now I've decided that I want to move 'B' back to 'A' and commit that change.
When I do the move and commit to my local master it works fine, but I get the following when doing a git svn dcommit:
Transaction is out of date: Out of date: 'A' in transaction '3652-1' at /opt/local/libexec/git-core/git-svn line 570
So I tried to copy and delete in a separate commit which resulted in:
Item already exists in filesystem: File already exists: filesystem '/usr/svn/db', transaction '3652-1', path 'A' at /opt/local/libexec/git-core/git-svn line 4735
I've recovered from this situation with plain svn by using the workarounds like the one described in the documentation, but I don't know how to recover with git-svn. What is going on and how do I fix it?
Removing .git/svn did not work for me. Instead, here's how I resolved:
Deleted the offending directories from the repository (But I'm not sure that this is necessary. In hindsight I think I could have skipped this step)
git svn rebase
During the rebase, there were some conflicts. For each conflict, I resolved the conflicts in text editor, then used git add <file-in-conflict> and then git rebase --continue
After rebase completed successfully, git svn dcommit ran successfully!
I can't claim to understand what's really going on under the hood in git-svn in this case (although the underlying SVN issue makes perfect sense). My usual strategy when git-svn gets confused somehow is to blow away the .git/svn metadata directory (as in this post). This almost always saves me from odd synchronization issues between the git and SVN repositories.
It happened with me when I interrupted the dcommit process.
Follow these steps to recover from error:
git svn rebase
You will get conflicts in files. Resolve the conflicts & then git add filename (in which conflict occurred) for each file.
Now do git svn dcommit. It will be pushed to remote successfully.