I would like to present in my GUI the SVN version of a certain file added to the project without hard-coding it each time I change something in the file and re-upload it to the SVN.
Is there a way to do that?
You need to use Subversion keywords, expressed as subversion properties on the file using the svn:keywords property. You'd set svn:keywords to Revision or Id to solve your problem. (Note that this solution updates data in the file, which is exposed when viewing or editing the file. It may or may not be shown an any particular GUI which is not a file editor.)
For more information on svn:keywords check out Special Keywords
For TortoiseSVN, right-button the file, pick TortoiseSVN, Properties, new, Keywords, and check the ones you want applied to the file.
Then, in the file, insert (in comments) the special strings $Revision$, $Id$, $Author$, etc. and Subversion will convert those into the actual data when the file is committed. Then, upon checkout, the data will appear and will be updated on the next commit.
If
your GUI can communicate with repository (i.e data is Working Copy or
you know filename-URL relation)
and
Production system has SVN-client
you can for any file-type get file-revision dynamically
svn ls -v URL (first column) or svn info URL ("Last Changed Rev" string)
Related
To let you understand my problem, i must give some brief explanation about the way my client application works.
First, we create workspaces with allwrite set, this is because our programming language (PowerBuilder) does not writes directly to txt files, it writes to 'pbl' files, which are binary.
However we dont version pbl files and to be able to version each object inside a pbl we need to run some cmdcommand, which will output the classes within the pbl file to text files (one file per class), these text files is what Perforce must version.
The problem now is that the pbls are being listed as modified files (in fact they are), but we dont want them to be marked as modified.
I could put them in a ignore file, but there are some Pbls in the repository which must be synced.
I know i could specify in the ignore file to ignore Pbls except the Pbls which are in the repository, but then these specific pbls would keep showing up as modified files when i run a reconcile..
What i want is to have the PBL file exactly the way it was before running the reconcile, unopened by perforce but modified.
Its would be ok, if i could revert them without undoing its modifications...
Or if i could run a reconcilefor all the files, except the pbls.
Does anyone knows a way to do that? Thank you.
You can revert files without refreshing their content from the repository by running 'revert -k': http://perforce.com/perforce/doc.current/manuals/cmdref/p4_revert.html
I currently have a project which I want to add to SVN but I don't want to version certain file types. (e.g. .png) or a folder (images).
I know there's the svn:ignore, but this will not work if there's no .svn file in the directory which I'm trying to perform the ignore operation. I get the following errors :
property 'svn:ignore' set on '.'
svn: 'common' is not under version control
I'm looking for someone to inform me as to how to do this or direct me in the right place.
Any time I'm trying this, its like I have to add the file/directory to svn using 'svn add' and then run the ignore. I've a lot of directories and I'm looking to do this recursively also.
Is there a simple way to do this?
Set global-ignores in Subversion configuration file (normally found on Linux at ~/.subversion/config). See the manual for more info.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
My problem is that whenever I update a folder via tortoise svn I get the files that were edited and now different from revision 1 to revision 2, SVN adds a "<<<<<<" to places that were affected.
Can anyone please provide some sort of solution?
These markers indicate where there have been conflicting changes between what you have changed and what somebody else has changed. The SVN Book has a section on merging which shows you what to expect. The book talks about the command line commands but the workflow for TortoiseSVN is similar.
See in particular the section titled "Merging conflicts by hand".
This lines are inserted by the default tortoise merge program.
If you change the default program to see the file differences you will not see this ugly <<<<<mine anymore. Use for example Winmerge
To use winmerge for file changes do the following:
Right click on a versioned folder and select Tortoise SVN->Settings
In External Programs->Diff Viewer section you can set the program you want to see file diffs. Select winmerger or you prefered.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)