Is it possible to add comments into the Artifact paths field in Team City? What format should I use? I'd like for the next guy to be able to quickly understand what is going on and why.
You can use anything that doesn't match a file. It will show up as warning in the build log (matching artifacts not found), but do no harm otherwise.
I use a hash to start comments, for example:
# Collect all DLLs from unicorn
unicorn/**/*.dll
Related
I am looking for the official terminology for the concept that comprises these 3 fields.
It's referred to as the "GAV" (groupId, artifactId, version), or, more rarely, "coordinates".
After searching around for a bit longer, it seems like its called the 'coordinate': https://maven.apache.org/pom.html#Maven_Coordinates
Although the coordinate may comprise additional fields, I suppose this might be as specific as it gets.
I'd say it's the identity of an artifact.
I am sometimes having conflicts when merging two branches using subversion.
This is not a real problem, as I just have to look at the actual code and solve them one after the other.
But I usually don't want to solve them during the merge process, as tortoise wants me to do and solve them afterwards.
Thing is our codebase is quite huge, and it takes a lot of times for the icons to refresh which makes it quite difficult to track down conflicts quickly.
So what is the best/easiest way to have some kind of listing of all the current conflicts in a repository ?
Any idea is welcome, I can also use another tool or the command line as soon as the solution is efficient.
Thx!
svn status will help you to see postponed merge-conflicts (which also block possibility to commit)
Extraction from svn help status
The first seven columns in the output are each one character wide:
First column: Says if item was added, deleted, or otherwise changed
...
'C' Conflicted
Second column: Modifications of a file's or directory's properties
...
'C' Conflicted
Seventh column: Whether the item is the victim of a tree conflict
...
'C' tree-Conflicted
Ok, here is what I found to get around :
In whatever repo you know have conflicts, you can use
right click->Tortoise SVN->Resolved.
This will list all conflicts in the repo, taken recursively all subfolders too.
Find a target that is big enough for you, and resolve your conflicts till the list is empty.
You can even resolve them directly within the window is you wanna go faster.
Group resolve also works for elements in the same folder that have the same kind of conflict.
Hope this helps someone :)
/* $Id: file.c,v 1.0 2010/09/15 01:12:10 username Exp $ */
I find this line in many source code files in the comment at the top (header) of the file. Why? Is it aimed for the version control software? -Thanks.
These sort of comments are automatically modified by various source code control systems, things like author, date, history and so forth.
See here for some common ones for RCS which is the first source code control system I ever saw to implement this sort of thing (that doesn't mean it was the first, just that RCS was the first I ever used and it had that capability).
One particular trick we used to use was to put the line:
static char *fileId = "$Id: $";
into the source file (and header files as well, although the names had to be unique) so that, when it was built, it would automatically have the ID of the files in the executable itself.
Then we could use something like strings to find out which source files were used to build the executable. Ideal for debugging problems in the field.
It tells CVS (and other VCSs) to expand the value of the Id at check-out time, so anybody reading the source file in question will know what version exactly was checked out for it. Not very popular any more (you can always ask your VCS for such info if you keep the source file in a client / repository / working directory -- or however else your VCS calls such things;-).
I believe you are correct. It appears to be a keyword substitution string for CVS.
Take a look at this question $id: name of file, date/time creation Exp $
So the directory layout would look like:
Visual Studio 2008\
Projects\
MyCompany.MySolution\
Models\
Models.Tests\
Services\
Services.Tests\
UI\
etc..
rather than
Visual Studio 2008\
Projects\
MyCompany.MySolution\
MyCompany.MySolution.Models\
MyCompany.MySolution.Models.Tests\
MyCompany.MySolution.Services\
MyCompany.MySolution.Services.Tests\
MyCompany.MySolution.UI\
etc..
The namespace for each project would of course be MyCompany.MySolution.MyProject.
The question was generated by concern over maximum character path limit of 260. It seems better to me to do whatever I can to be able to freely name my projects and solutions; however, I don't want to run into an unforeseen mess.
If you run up the character path limit, you have to do something and you have to get creative. In this case, it is reasonable to alter the filename to a less-than ideal convention. Demoting the project names from including the complete namespace to merely the project name seems reasonable. Otherwise, consider using acronyms whenever you can. This approach will help a bunch.
I'm working in XCode and I've also written an external editor tool that generates resources for use in the project. In the best case scenario, the tool would edit the project.pbxproj file so that it includes the generated resources in the project. I've read through the file in an attempt to understand it, and it's mostly discernible but there is still one major question I have.
If I wanted to generate a new Group from outside XCode (or a new anything, for that matter), how do I know what ID code to use? For example: 19C28FACFE9D520D11CA2CBB is one of them from my project. How am I supposed to know what to use if I make my own? Do they just need to be unique? Would it be legal to just make one up: 000000000000000000000001 and 000000000000000000000002 and 000000000000000000000003 etc. ?
Any help on this would be wonderful. Thanks.
Yes, you can make your own. The best way would be to use a hash function such as MD5 or SHA1 to generate it then you can truncate it at the desired length. I would hash the name of the file/group along with a time stamp appended this way you get a more unique result.