I am in a circular trap here...
We are building on a dedicated server, so when we do a pull and build I want to update the version information in the projects to show a version such that the last digit is the "revision" number at that current pull for subversion.
But if the script updates that file, then it is not current. So I need to re-commit that file, or merge it in the next pull, or ...? Then the revision number is incremented.
I solved it in a C++ program by placing the actual revision numbers in a file that was NOT under the control of SVN. Now the script can "svn update", capture the revision number, change the local file, and built. However that creates a dependency on a file that is not under SVN control.
Furthermore, there are projects where it appears I cannot externalize the version number into a dedicated file, and leave that file out of SVN control.
What I really would like to see is a "eyecatcher" tag that SVN would update upon an svn commit (or svn update). Something arbitrary like: {!SVN_REV}
So, my C# assembly file might look like this:
[assembly: AssemblyFileVersion("1.1.0.{!SVN_REV}")]
Other version control systems support this kind of ability. Is there anyway in Subversion to do it?
Thanks for any advice.
Scotty
if the script updates that file, then it is not current
No, it's current (it terms of information), you can just not save this minor change in repository (best and easiest way)
From other side, you can
Store template-file in repository (read about SubWCRev and it's keyword)
At build stage create additional not versioned file at first stage with keywords, substituted with real (actual data) and use this file, not template
Related
Is there any way to move classes from one source code file to a new one without losing version control history? We are using TFS.
Thanks.
It's based on which version control system you are working with:
This not possible with TFVC as Marvin Glenn Lacuna also described very clearly above, However you could try the following workaroud:
Branch FileX to FileA
Branch FileX to FileB
Open each file and delete the party you don't want
Delete FileX
Now you could maintain history on all of the visible lines of pre code
through the branch relationship.
For GIT, you could take a look at this question: How does git track source code moved between files?
In TFS, from my experience, the simple answer is no, it stays on the source file and will remain in the source file. It will not be copied to the target file (ctrl+c, ctrl+v). I believe that's why it is called "file history" and not file section/classes history.
With current TFS version, the default version control is Git.
So you could do it by a trick.
Assume that you have two classes ClassA and ClassB in a file named File.ext, your source code is at branch master.
The steps should be:
Create branch 'developA' from 'master'
Call 'git mv File.ext ClsA.ext' then commit to have ClsA.ext with history of File.ext
Cleanup ClassB in ClsA.ext then commit.
Create branch 'developB' from 'master'
Call 'git mv File.ext ClsB.ext' then commit to have ClsB.ext with history of File.ext
Cleanup ClassA in ClsB.ext then commit.
Merge two branches 'developA' and 'developB' then push to 'master'
Now you have both files ClsA.ext and ClsB.ext without losing their history from File.ext.
An example could be found at my github repository.
I was building a DataAccessLayer using C# in VS 2012, and in my project, there are three files which I don't know how to deal with.
DataAccessLayer.csproj.mine
DataAccessLayer.csproj.r60
DataAccessLayer.csproj.r72
What are they? How should I deal with them?
They are files created from your repository that the code is saved in. You did an update and when you try to commit your files you will get a commit failed probably. When you diff the files, it will use the .mine .r60 .r72 files to bring up the differences between each revision (.r60, r72) and your file (.mine) and allow you to do something like Keep all changes in mine.
In order to get rid of the commit failed error messages, find the original file, update it with the correct changes, and when finished right click it and Mark as resolved and commit. This will get rid of those files.
Those files are related to version control (.mine is your file, .rX come from revision number X). You should try to merge them using your version controlling tool if you have one. If you don't have one and got those files by copying a project, you can possibly delete the .r files and rename DataAccessLayer.csproj.mine in DataAccessLayer.csproj (unless you already have DataAccessLayer.csproj - just keep it and delete the other then). Edit: And if it causes problems, try merging them manually (using a text editor for example) before keeping the final file.
I am using the most recent version of anksvn for a visual studio 2008 project file. I now
want to check this code into anksvn, but I am having a problem.
The situtation is, I checked in the most current version of code into anksvn. That is fine.
However I have another version of this code that I did not check out from subversion initially. This other copy of the code was for a 'demo' only. However now this code needs to become the production code. Thus I am trying to determine how to check this code into anksvn.
What I know I can do is to 'remove' the most curent code folder that is in anksvn. I could then place this project folder into that location. since the origianl 'demo' code also includes the current production code.
However I am trying to see if there is a better method to accomplish this goal. Could I possibly use the branch/switch option?
Is the demo code checked out of Subversion at all? I know you didn't check it out, but was it checked out? If it was, you could commit this code back into Subversion, then update your working directory.
It his code has nothing to do with Subversion, you will have to take a more complex route: You will have to copy the changes manually to your code.
Since you're using Windows, you should take a look at Beyond Compare, This is commercial code, but you can download a limited time demo for free -- more than enough time to handle your situation. I use Beyond Compare all the time to compare two different directories or Java jar files or zip archives, etc. It not only can quickly show you the differences, but makes it each to copy those differences from one to the other.
I have no relationship with Scooter software, the makers of Beyond Compare except as a customer.
Is there any possible way to prevent files in a folder being removed or from over written during re installation? i have a folder where i store some templates for sending mails which user can edit.I have added the basic templates in my setup and so during re installation it removes the templates which the user might have already edited and places a new copy of the template.How can i prevent this?Should i use installer class or is there any property that i can use?Please Guide.
See:
File Versioning Rules (Windows)
Especially:
Neither File Has a Version (Windows)
You are using a tool that makes every single file a key file of it's own components. Therefore, you should already be getting this default behavior. If you set Permanent, they should not get removed. You said that the use "can" modify these files. The behavior is that if they haven't modified the files, they will get overwritten and if they have modified the files they will not.
However, IMO, a better pattern is to have an override directory that users can copy templates to and modify. You can get into undesired behaviors on upgrades resulting from the conflict of 1) My new build fixes something and 2) I can't install it because the old stuff has user data. This is especially true for things like XML files.
this can be done by selecting the file properties and setting the value of permanent to true.
We are working with two different teams on the same project. In a configuration file App.config, we have two connections string with our connection settings to connect to our database and the second team has another database with a different connection string. I have to comment the second connection string and uncomment the first. I have to check always this file if the connection string is correct (if the another team has not commited this file). It's a little bit boring..
This configuration file contains some other configurations keys that we use in common. My goal is to set (on the config file with a or somewhat) to tell to SVN to not include this part of file when I made a commit.
Is it possible ?
Partial file commits aren't possible in any version tracking system I've ever seen. You can however take a look at something like this if you're using VS2010.
You can use the configSource attribute to have ASP.NET read the config from an external file instead of the main config file. That way you can have one dirty and ignore-on-commit file containing the connection strings, and still be able to commit the main config file when changes are needed.
I suggest that everyone in your teams backup the configuration file, and have someone rename the file in SVN to something like template.[original-name] and commit that.
Then, have everybody restore their own configuration file and put in into the svn:ignore Subversion property of the directory containing the file, and commit that directory to have the svn:ignore in version control for everyone and have them update their working copies after that.
This way, each team member can have a different configuration.
Configuration and user/system specific files should not be in version control.
See also http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html.
EDIT: To actually answer your question, David is right, partial file commits are not possible (and usually would not make sense either). It is not the intended workflow of Subversion.