I would like to prevent the files promoted to an Accurev stream which have spaces in the file name.
e.g.
My image.png
If anybody tries to keep / promote the above file, I would like to prevent that.
You would need to add this logic into the server_preop_trig. You will add it to both the keep and promote sections of the trigger.
Related
I'm using ExifTool to add keywords to a file. I do this in batch, spawning ExifTool as a child process from my app.
exiftool -keywords+="courgettes" -keywords+="edible gardening" -keywords+="vegetables" -keywords+="Glasshouse" -keywords+="Greenhouse" -overwrite_original "/pictures/garden/P8151927.JPG"
However, it seems that with -overwrite_original the process isn't 100% transactional and atomic; occasionally it fails for some reason or other, but instead of leaving the original file untouched, it leaves it renamed to P8151927.JPG_exiftool_tmp. This means it looks like the original image has gone missing.
Is there any way to guarantee that if the ExifTool update fails, the original won't be touched? My understanding was that it would create a temp file with the new/changed keywords, and then carry out a transactional delete/rename which would either work or not, but it seems the delete can succeed, but the rename from the temp file can then fail.
Is there any way to work around this - any additional options I can use to make it 100% resilient? If not, my only alternative is to copy the file to a temp location, run exiftool on it, and then handle the rename/replace myself. Alternatively, I could check the return code, and if non-zero, I can rename the .JPG_exiftool_tmp file back to the original, I suppose.
Any better ideas?
I have temporary files created in separate folders inside my source tree which I would like to ignore. Something like:
project/
|--component/
|--.jazzignore
|--file.src
|--file-9df29e29373e66caef72/
|--file.src.tmp
I already ignore file.src.tmp by extension using .jazzignore, but I would also like to ignore the file-9df29e29373e66caef72/. The folder looks empty in the "Unresolved" category for the component, but since its name changes over time, I cannot ignore it by name.
since its name changes over time, I cannot ignore it by name.
Still, if you know its naming convention, you might consider an ignore pattern:
core.ignore= \
file-*
Note it is non-recursive, you that would ignore any file, folder or symlink named file-... anywhere under component.
Here, that would ignore only file-... directly under component.
Eclipse workspaces often include files or folders, such as compiler output, log files, and so on, that you do not want to place under source control.
You can specify resources or classes of resources to be ignored by Rational Team Concert™ source control. Ignored resources are never checked in.
A .jazzignore file is used to prevent items from being checked into change sets.
A .jazzignore file consists of a series of patterns. Any file, folder, or symbolic link whose name matches a pattern cannot be committed to a change set.
There are two types of patterns in a .jazzignore file:
core.ignore patterns, that are effective in the same directory as the ignore file; and
core.ignore.recursive patterns that affect items in all of the directories below the .jazzignore file.
We are using Mercurial as an SCM to handle the source script files of a program. Each project we manage has ~5000 files with each file containing a section with some product-specific informations about the file itself (version list, date, time etc.). This section is - due to the way it is structured - in 80% of the merges, the only section that has conflicts. They are easily resolved, but when merging around 300 files, it gets tiresome.
The problem is: I have no control over the way this section is written and I cannot change the format of the section itself, as it would make the file unusable by the program.
My question: is there a way in mercurial (hooks?), that allows me to
pre-process the file with a script
let mercurial do the merge
if merged correctly: post-process the file with a script. otherwise: "resolve-conflicts" as usual.
You could probably get away with it by creating a custom merge tool:
https://www.mercurial-scm.org/wiki/MergeToolConfiguration
A simple script that invokes 'diff' after removing the ever changing sections might be enough.
It sounds like those sections are the sort of nonsense that the (disrecommended) KeywordsExtension are built to handle, but I gather you don't have a lot of flexibility around them.
I'm in the process of building a Lemonstand site, which I'm managing via git. As such, I'm using the following .gitignore rules:
# Lemonstand
.htaccess
php.ini
boot.php
index.php
install.php
/config/*
/controllers/*
/init/*
/logs/*
/phproad/*
/temp/*
/uploaded/*
/installer_files/*
/modules/backend/*
/modules/blog/*
/modules/cms/*
/modules/core/*
/modules/session/*
/modules/shop/*
/modules/system/*
/modules/users/*
# add content_*.php if you don't want erase client changes to content
/modules/gallery/*
/modules/lddevel/*
/modules/tweak/*
(The top block I got from github, with the second block being some additional rules I added myself to avoid issues with Lemonstands updating system).
My problem is that I'm adding a custom invoice to Lemonstand, which (to cut a long story short) requires the addition of a folder and some files within /modules/shop/invoice_templates/, which I've named cm_standard.
Because this is extra to the default Lemonstand, I want to get this tracked with git, so I'm trying to use the following rule to the bottom of my gitignore file:
!/modules/shop/invoice_templates/cm_standard/*
But when I do a git add -A, it isn't picking up the files within that directory. Even if I do a git add modules/shop/invoice_templates/cm_standard/* it tells me:
The following paths are ignored by one of your .gitignore files:
modules/shop/invoice_templates
Use -f if you really want to add them.
fatal: no files added
Which further suggests I've not written the rule correctly - can anyone help? Thank you.
Ignore patterns with fewer path segments can take precedence over patterns with more path segments, so in your case /modules/shop/* is taking precedence over !/modules/shop/invoice_templates/cm_standard/*, effectively pruning the whole of /modules/shop/invoice_templates/ from the directory traversal even before it looks at the contents of !/modules/shop/invoice_templates/cm_standard. Having said that, ordering can matter too, and when it does, somewhat counter-intuitively later rules within a file take precedence over earlier ones.
This question is very similar to How do gitignore exclusion rules actually work? so I suggest you read that. Also you may find the check-ignore subcommand useful when debugging rules - I added it to git over the last few months and it just appeared in version 1.8.2 which was released a few days ago.
Is there any way to have the same file be a part of multiples changelists in perforce? With that I mean that from the set of changed lines in the file one subset will belong to a changelist, while the other subset will belong to a second changelist.
Bonus question: If perforce does not support this, then which Source Control Systems, if any, do?
To answer the bonus question: GIT allows for per-line changelists.
For a comparison between the two view this question: GIT vs. Perforce- Two VCS will enter... one will leave.
The same copy of the file? No, unfortunately this isn't possible.
Another way to do this without branching is create additional workspaces (clients). Unless you really know what you're doing, be sure to set a different root directory in each of your workspaces. To save time (and disk), don't bother syncing the whole depot in the new workspace.
Sometimes, I'll have two copies of a depot (using two workspaces); one which contains work-in-progress and one which I keep unmodified. If I need to make a quickie change on a file that's heavily modified in my WIP workspace, I can use the 'virgin' workspace to make the change and submit it.
If you are using p4 server 2009.2, there is a workaround to do it. You can shelve a particular file and the diff is stored on the server. After shelving you may want to revert the file to its original version and then work it on in another change-list.
I know this is not a way you wanted it but it is quite easy to create another workspace/client and then sync the code. The later exercise becomes more tedious when you have volumes of code that goes into another application.
For more info read:
http://blog.perforce.com/blog/?p=1872
http://www.perforce.com/perforce/doc.current/manuals/cmdref/shelve.html
You could make a copy of the file with all of the changes, revert, edit the file copy one set of changes into the file, submit, edit, copy the next set of changes, submit, edit, etc...
Bonus answer: I found this feature in Rational Team Concert (http://www-03.ibm.com/software/products/en/rtc/). You can have the same file in many changesets. If you want to add File1 to Changeset1 and Changeset2, you must complete Changeset1 first. This allows you to add File 2 to Changeset2 but then a dependency between changesets is created, so you can not deliver Changeset2 without delivering Changeset1 too. Moreover you can not make changes to a complete changeset.