I would like to link a repository file in a redmine project with multiple repositories. So I have something like
source:svn1|/path/to/file
But I want that inside of a table and so I need to escape the | because it is interpreted as column separator.
|_. File|_.Description|
|source:svn1|/path/to/file|awesome|
I am facing the same problem when trying to link a revision inside a table.
|_. Revison|_.Description|
|svn1|r758|Bug|
Has anyone an idea?
The solution is using <notextile>|</notextile> to escape the | in the repository link. So
|_.File|_.Description|
|source:svn1<notextile>|</notextile>/path/to/file|awesome|
does the job. The same works for a link to a revision inside a table
|_.Revison|_.Description|
|svn1<notextile>|</notextile>r758|Bug|
Related
I have a TeamCity Build Configuration that includes the following to publish artifacts:
Source\Builder\bin\Release\*.dll=>release
This works fine, however I am wanting to exclude one dll (there are quite a few) and have read that you can use + & - operators to do this. Something along the lines of:
+: Source\Builder\bin\Release\*.dll=>release
-: Source\Builder\bin\Release\Builder.*
As soon as I add these in, no artifacts are published and I get the following error in the build log (looks like it is counting the + as part of the path):
[Publishing artifacts] Collecting files to publish [+:Source\Builder\bin\Release\*.dll=>release]
[Publishing artifacts] Artifacts path +:Source/Builder/bin/Release/*.dll not found
I am using version 7.1.1, anyone any ideas (I am not sure whether these operators are even valid). I have seen a solution with MSBuild but am surprised this functionality is not available.
Thanks in advance.
I don't believe you can.
However, if you are using the artifacts in another build configuration as an artifact dependency, you can exclude a particular file there.
When you set up the dependencies, you can specify a negative operator like this:
+:release/**=>Dependencies/SomeProject
-:release/SomeBinary.dll
It is a horrible hack, but one way you could get it to work would be to set up a new build configuration which gets the dependencies as an artifact dependency, excluding the one binary, and then publishes its own artifacts.
As in, create a new build configuration and publish:
Dependencies/SomeProject=>release
Then reference the artifacts from this build configuration instead of the other one.
A little bit late for the party, but there is still no fix...
I ended up adding a last build step to the project. It is command line > custom script. Then I used this commands to remove the files that I didn't want in the artifacts. This runs just before artifacts collection.
del /S /Q "src\apps\*.xml"
del /S /Q "src\apps\*.pdb"
Explanation for del command
/S Delete from all Subfolders (DELTREE)
/Q Quiet mode, do not give a Yes/No Prompt before deleting
* Match any characters
Our current options are to vote for this feature request at
http://youtrack.jetbrains.com/issue/TW-5244 and fail back to workarounds.
TeamCity artifact paths combine folders question hints that the same target folder can be reused for multiple path patterns.
TeamCity docs also state that
TeamCity will create directories starting from the first occurrence of
the wildcard in the pattern.
So in many cases it's possible to inverse exclusion problem to multiple inclusions.
For example, instead of lurking how to exclude -:**/.svn from my templates I was able just to filter them by extension:
templates/**/*.vm => templates
templates/**/*.xsl => templates
I am new to build on TFS 2010.
I have 4 C# solutions. One of these solution has a dependency on the assembly produced by each of the other 3 "helper solutions".
I'd like to create a build definition which would build my 3 helper solutions then build the top level solution.
On the build definition dialog I have tried to add each of the 4 solution files to the Workspace tab, with a build agent folder of $(SourceDir) - but I get the error dialog "TF215040: The path $(SourceDir) can only be mapped one time in a given workspace". So I change the mapping for the helper solutions to the build folder used by their respective individual build definition.
On the Process Tab, under the Items to Build property I've added the solution file for each of the 4 solutions, with the parent solution listed last.
When I queue the top level build defintion I get the error message: "The path C:\Builds\3\x.Int.Common\x.Int.Common\Sources is already mapped in workspace xBLD01."
Note: when I run "tf.exe workspaces /owner:*" I notice that my workspaces is listed multiple times, with different owners but the computer name is also the same. I guess this is because there's 3 in the team using the same VM image - they're not connected to the domain. Maybe this is the cause of the problem?
Could anyone please suggest a solution?
Thanks
Rob.
Just map the root folder that contains all 4 solutions under it in the workspace mapping. For example, if your folder structure looks like this:
C:\MyProject\Solution1\1.sln
C:\MyProject\Solution2\2.sln
...
Just map C:\MyProject\ -> $(SourceDir)
If the workspace mappings have gotten messed up on your build server you can download the TFS SideKicks tool to delete all the workspaces on the build server, and the TFS Build will just recreate them proper ones next time you run it.
I'm moving from StarTeam to SVN, and I've decided to take snapshots of each of our releases. However, I'm experiencing a problem when dealing with files which existed in revision 1 were deleted for revision 2.
How do I commit the snapshots when files are missing?
I've tried fully deleting the trunk/src/ folder and then replacing it with the new /trunk/src/ folder, but that seems to cause conflicts with missing files. When I
svn add" everything, TortoiseSVN seems to detect that the files were missing, and when I commit it seems to attempt to delete the missing files, but it seems to fail. Presumably this is because it's trying to delete directories after deleting the files in that directory?
I'm getting the following error:
deleting C:\trunk\src\myfile.h // this one's okay
deleting C:\trunk\src\res
Commit failed (details follow):
Directory 'C:\trunk\src\res' is out of date
Item '/trunk/src/res' is out of date
You have to update your working copy first.
What is a solution to this problem? Surely I'm not the first to run into this issue, but I cannot seem to find anything on google or stackoverflow. Some people suggest running a script to do it, but I'm still confused about the process. Do I need to delete my old trunk folder so that the missing files will get removed locally? Or should I diff and delete with a script?
Thanks!
Old (unclear) post: Migration to SVN, confused about deleting old files
Edit:
This is going from one snapshot to the next. I'm migrating from a different repository (StarTeam), so I didn't have anything in trunk. I just want to check in all the different snapshots and have the files which were deleted be removed as well. Isn't it a bad idea to tag if I don't have anything in trunk?
There's actually a Subversion script that does this for you called svn-merge-repos.pl
I'm not 100% sure you're understanding the concept of how Subversion works. Did you go through the Subversion book?
In Subversion, there are no real tags/labels or branches metadata like you find in many version control systems. Instead, you put tags and branches in their own directories. To create a branch or tag, you copy what you want to branch or tag into the directory:
# Creating a branch for 2.0 development from trunk
$ cp http://server/svn/module/trunk http://server/svn/module/branches/2.0
# Tagging my 2.0 development as 2.0.1
$ cp http://server/svn/module/branches/2.0 http://server/svn/module/tags/2.0.1
In theory, you can simply create a new branch or tag directory for each release and branch you're working on without a need for merging repositories. That's what I did when I did a StarTeam to Subversion conversion. The problem is that you lose the relationship between say revision 2.0.1 and 2.0.2 since they don't share a common history. 99% of the time, that's not really a problem, and you can always go back to the original StarTeam archive if you need anything. In a few months, no one will care.
However, if you know the relationship between branches and tags, and want to keep that information, you'll have to do the two step script I described above.
For example, you have a 2.0 branch that comes from trunk, a 2.0.1 tag, a 2.0.2 tag, and a 2.0.3 tag, you might want to do this:
Put branch 2.0.1 release onto trunk.
Copy trunk to branches/2.0.
Put the next branch on trunk and copy it to its branch (use the svn-merge-repos.pl script)
Finally, put the current trunk.
Now go to that branches/2.0 directory and copy that to tags/2.0.1. Using the svn-merge-repos.pl script, create the 2.0.1 release on branches/2.0 and copy that to tags/2.0.2. Keep going until you get to the tip of the 2.0 branch.
That takes a lot longer to do, but it's feasible. Last time I did that, it took me about a week and a half to do the entire conversion. Fortunately, I did the trunk first and then the active release which I could do in a day. Then, worked my way back to the less active stuff.
I'm certainly not an expert on SVN, but I believe that you've got to issue the svn delete command for the items you want to delete upon the next commit. It's described here.
You should create a tag instead.
EDIT:
svn status list all changes
you can print all deleted files like this:
svn status | grep -E '^!' | awk '{print $2}' > /tmp/changes
You can do a svn delete on each file with a batch ;)
EDIT: (SVN Migration How-To)
Let's assume you have a project named projectA, and a blank SVN repository.
First, you should create a Folder structure like this:
projectA/
|-- branches
|-- tags
|-- trunk
Then import your project files.
projectA/
|-- branches
|-- tags
`-- trunk
|-- README
`-- src
After the import you can create a tag to "mark" the initial release:
projectA/
|-- branches
|-- tags
| `-- release-1
`-- trunk
|-- README
`-- src
After this point, you should edit your files as you like.
When you think all your edits are "Good", then commit.
After some commits, if you want to release, create a tag.
Trunk should always contain the up-to-date version of your code.
I highly recommend you to use TortoiseSVN on Windows if you are a rookie ;)
You should use svn-load-dirs.pl:
"This Perl script is designed to load a number of directories into
Subversion. This is useful if you have a number of .zip's or
tar.{Z,gz,bz2}'s for a particular package and want to load them into
Subversion."
Basically what you do is:
export all you tags chronologically
create an empty repository
use svn_load_dirs.pl to "stack" tag after tag in your subversion.
svn_load_dirs.pl creates a single revision for each tag and you can as well create a (subversion-)tag after each import. It will keep track on all deleted and added files and will perform the appropriate svn actions. This means you can explicitly start with an empty trunk
From your question, it looks like that you are completing misusing SVN. There is no point in deleting the entire trunk/src folder and replacing it with a new one except in case of a huge change in the code.
Instead, create a tag for the release.
If you have two separate projects that is somehow connected. How can one make a reference to the source of the other project?
For referencing the source of your own project you use:
source:some/file
But since I want to refer to code in another project my thought was that I could write something like:
other_project:source:some/file
Anyone that knows if this is possible in some way? I have read http://www.redmine.org/wiki/redmine/RedmineTextFormatting#Redmine-links but found no clues there.
Apparently this was implemented in Redmine 1.2.0 (released 2011-05-30). The syntax is exactly the one you suggested in the question, other_project:source:some/file, other_project being the project identifier.
It is possible in a couple of ways - although neither solution is particularly neat.
use an external html link to the other_project source code, where other-proj is the identifier for the other project.
"other project source":http://myserver:3000/projects/other-proj/repository/entry/file.txt
define the source path via the parent directories, so from the source directory of your current project go up 3 directory levels before navigating back down to the repository of your other project. Note the source link needs to be inside double quotes to work. This method at least keeps the source tag at the front of the link.
source:"../../../other-proj/repository/entry/file.txt"
The Redmine Text Formatting page says the format is:
source:repo_identifier|some/file
Even so, the selected answer works for my version of Redmine (1.4.2), but it may have been changed in later versions. This link format was added to that wiki page on 2012-08-27, after OP asked their question.
I have a django project that I have been working on as a solo developer, and have been using TortoiseSVN to keep the code managed in a repository on a work server. I work on this on a local installation of django etc.
There is now a second person who will be working on this project, and the possibility of working on some other PCs.
Now, there should, for the time being, only be one development version (branch?) of this project, but the configuration file (settings.py) will need to be different on each computer that is being used. I want to create one local version of this file on each PC which should not need to be changed again.
How can I set the repository (preferably within TortoiseSVN) to exclude this one file? E.g. the repository should not include settings.py. When a checkout occurs, it should update all files in the local folder but not change/remove the local copy of settings.py. When a commit occurs, settings.py should be ignored and not uploaded.
At the moment settings.py is overwritten/updated as per any other file in the project folder/repository.
Any nudges in the right direction would be useful - I'm new to SVN generally and would like to know if this is something that's going to need detailed understanding of branching or if there is a simpler way.
Thanks
In TortoiseSVN, when you try to commit your files, in the file list dialog, right click the file and look for the Ignore option. You can ignore by complete filename or extension.
If the file is already in the repository, and you want to remove it from there and ignore it, you can simply right-click the file and in the TortoiseSVN menu look for the 'Delete and add to ignore list' option.
You'll be looking for the svn:ignore property, which tells subversion to not version files matching a pattern or patterns you specify.
There's some guidance on using it with TortoiseSVN at:
http://arcware.net/tortoisesvn-global-ignore-pattern-vs-svn-ignore/
These should help:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
Excluding Items from the Commit List
The typical solution is to do what bgever said and ignore the settings file itself, and then commit a file with example values, something like settings.py.example. That file should only be updated when you add or remove settings. When deploying, you'd copy that to settings.py and edit the values.