I am using Subversion to manage my python code. But I have no idea how to put the file properties of my configuration file.
For example I have the configuration file checked in on my development platform. I want to make sure that
After the configuration file is being checked out. The SVN up process should ignore the modified configuration file.
On the server side I have the golden configuration file. Therefore the SVN commit should ignore the configuration file as well.
I have no idea how to set the properties of the configuration file so I am seeking help here.
Thanks in advance
This comes up enough that it's in the Subversion FAQ
Short version: Create (and version) a "template" configuration file. Users check out a WC, make a filesystem local (not svn) copy which is to be ignored by Subversion, and then modify that copy.
You might want to look at my pre-commit hook.
But first, uou need to remove that configuration file from your Subversion repository. Instead, add a configuration template that developers can copy and use.
Once you remove the configuration file from your repository, you want to set svn:ignore to ignore it. This way, it doesn't accidentally get added if a user does a svn add * or sees it when they do a svn status.
However, if you want to be absolutely certain that this configuration file is never added to the project, you need a pre-commit hook that will refuse a commit if a user does add it.
Why don't you tell SVN to ignore the file?
$ cd path/to/config/file
$ svn delete --keep-local config.file
$ svn propset svn:ignore config.file
$ svn commit
What this does is first tell SVN that it should stop tracking the file (svn delete), then we set the svn:ignorepoperty on the directory in which the file resides, and then we commit these changes.
If you still want the configuration file to be tracked by SVN, then you can either commit your changes excluding the modifications on the file, or external the file in and be sure to ignore externals when committing.
Related
I want to have all my configuration files versioned using Git in a remote repository at Github. I'm using Debian 7 testing, and all my configuration files are under the /home/user_name/ directory.
I created the usual .gitignore with all the files that I want to ignore and the files and directories that I want to allow versioning. My problem begins when I go to Documents, for example, and I see in zsh that folder is under the same versioning as the home directory.
I understand that Git works that way, but I need to know if it's possible to avoid that.
One classic way to version configuration files is to create a subdirectory like ~/etc/ and let your ~/.something files be symbolic links to ~/etc/something. Then, you can version ~/etc/ normally.
You can manage to ignore everything but your configuration files, but you'll always have little glitches like: the day you run git clean -fdx in the wrong place, you delete all your data.
Write */ in your .gitignore to ignore directories. Make exceptions with !foodir. Consider prefixing with slashes (see documentation for details).
I've added a new file (pdf) to a directory and when I try and commit the new file it is saying that it is not under version control, the directory and every other file in the directory is under version control as when I tried svn add * it listed all the files as being under version control.
What is causing this problem and how do I fix it?
EDIT: OK I am now able to add the file, am I right in saying that the svn add * command added this file under version control thus allowing me to commit the file?
Yes, the svn add * did that.
You have to svn add Name_of_File any new files before you can svn commit them.
you can try something like this...
in the checkout directory run this command
svn add . --force
then just commit it all
svn commit -m "your text" *
In some cases the add command doesn't do it, and still gives an error. the best thing is to perform the svn cleanup [PATH...] command then try to add or commit.
I am attempting to create a git repository to store all of my dotfiles and config files. My idea was to simply create hard links to all of the files I cared about and store those links in their own directory that I could turn into a repository.
I've hit a bit of a snag though with my ~/.gitconfig file. It seems that whenever I run the 'git config' command the link that I created no longer points to the right location e.g. the file in the repository no longer updates properly.
Here is an example using the shell and interactive ruby to determine the files linked state.
# Create the link
$ ln .gitconfig .conf_files/gitconfig # Create the link
# The files are in fact linked
[1] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> true
# Update the gitconfig file by running a 'git config' command
$ git config --global alias.last 'log -1 HEAD'
# The files are no longer linked.
[2] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> false
I assume this has something to do with the way that git is writing the .gitconfig file. Does anyone know why this would happen, or have any creative ideas for a workaround?
Try Eli Barzilay's solution in his comment at http://www.xxeo.com/archives/2010/02/16/dotfiles-in-git-finally-did-it.html:
So I’ve finally found a solution that takes the best of both: put the repo
in a subdirectory, and instead of symlinks, add a configuration option for
“core.worktree” to be your home directory. Now when you’re in your home
directory you’re not in a git repo (so the first problem is gone), and you
don’t need to deal with fragile symlinks as in the second case. You still
have the minor hassle of excluding paths that you don’t want versioned (eg,
the “*” in “.git/info/exclude” trick), but that’s not new.
This is completely normal, and is in fact the recommended way to overwrite config files. Git creates a temporary file, writes out the config, and then moves the new file over the old one. This way, you don't get an incomplete config file (data loss) if Git gets interrupted.
You can always write a script to copy or link your config files into your central repository.
Checkout this answer, perhaps it may be of help:
https://stackoverflow.com/a/3731139/1431696
In the meantime, have you considered doing the links in reverse? Create your repository full of config files, etc, and then in the place that you actually use your files, create a hard link to the 'real' file, which sits in the repository.
Thanks to Dietrich Epp's answer and advice I have decided to approach this problem from a different angle by creating the repository at the root of my filesystem, and using .gitignore to track only the files I am interested in.
My .gitignore file now looks like this:
/*
!/etc/
/etc/*
# etc files
!/etc/rc.conf
!/etc/asound.conf
!/etc/mercurial/
!/home/
!/home/matt/
/home/matt/*
# Home files
!/home/matt/.xinitrc
!/home/matt/.gitconfig
!/home/matt/.bashrc
# Vim files
!/home/matt/.vimrc
!/home/matt/.vim/
.netrwhist
In addition to not having to copy the files separately and keep them in two separate locations this has the benefit that should I need I can easily revert the changes without having to manually copy the files as well.
Thanks for the help guys!
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
How do I upload a single file from my local computer to a SVN repository?
I can import a directory, but I can't import a single file into existing directory.
I use SVN in linux (command line).
Any help would be appreciated.
Edit:
I forgot to mention, I need to upload this file into a specific directory that has nothing to do with directory structure in my local computer (say I upload from Desktop).
So I want to upload a file from Desktop to https://.../somefolder
This can be done as the OP requires.
svn import -m "Adding a new file" file_to_upload.ext http://example.org/path/to/repo/file_to_upload.ext
This allows uploading a file directly into the repository without checking out to a local working directory.
Well, short answer is that it doesn't work like that :)
In SVN you work with a checked-out revision of your repository. In order to "upload a single file" you have to "add" the file with "svn add foo.txt" and then run "svn commit -m "Added file foo" foo.txt". But you can only do this to an existing repository. Therefore you must first checkout the revision (rev of trunk or a given branch) of the repository to add the file to. So the entire steps would be something like
svn co https://svn.internal.foo.com/svn/mycoolgame/branches/1.81
create your new file in the correct place in the folder structure checked out.
svn add your new file
svn ci -m "added file lalalalala" you new file
After this, you can delete your local copy again.
8-year edit: As mentioned svn import can also be used to accomplish this without having a local copy under version control. Do note though that this does so recursively and will add directories not present in the repository. This could be desired behavior or a source of potential errors depending on the situation.
svn add /path/to/your/file.txt
svn ci /path/to/your/file.txt -m "This is where the message goes"
Or if you havn't added anything else just commit with
svn ci -m "Your message"
svn add filename
svn commit filename