Say I use SourceGear Vault client on my desktop at work and check out a few files to a network folder. But when I am working from home and login to a terminal server (Windows RDP), Vault thinks that someone else has checked out the files and so I can't access/edit them.
Is there a way to set things up such I can checkout a file to a common network location and keep working on it from multiple machines?
Thanks
What you are seeing is normal, because the Vault cache is specific to each client.
Here are the options I could see for how to deal with this:
1) The best way is to shelve your code changes. Then you can pull your shelved changes down when you get home and continue where you left off. If you need to check in from home, then when you initially shelve your changes, you should also undo your check out so that you can check out again from home.
2) You could use a network location for yourself, but you are likely to run into the same situation when you go to check in. What this would give you is just the ability to have only one location for the code you are editing. Also, some of the statuses you see as you are switching between clients won't look right. You still would get best results by undoing your check out before leaving work, but in this case, you'd choose the option to leave your changes instead of reverting them back.
3) You can perform an additional check in. That way your code is in Vault. Then you can check it out again and continue from where you left off. Some places don't want partially completed code checked in though, so you will have to decide if this is in line with your workplace requirements.
4) You could perform a non-exclusive check out. That way you can check out twice. You will get a warning, but it will still allow you to continue. To get your changes from your work computer, you still will be well served by using Shelve.
Feel free to email me at support#sourcegear.com if you need additional help.
Thanks,
Beth Kieler
Technical Support
SourceGear LLC
Related
I am using PHPStorm 9.
I have installed PHPCS to sniff my code. It is properly configured, up and running.
I am working on a very old project, which was implemented in plain PHP, and not using any code standard.
As a result, every time I open any of those files, I get a message at the top of the screen saying that I have too many errors (code style errors).
I have a couple of problems with that.
First, I already know how bad the code is, so I don't need PHP Storm to tell me that all the time.
Second. That message appears and disappears every time I edit the code. As a result, the window editor is constantly moving up and down, which I find specially annoying.
Also, at the top of the screen it is showing me the breadcrumbs, to tell me where I am. I appreciate the help, but I don't actually need it.
So the question is, how can I configure the IDE to disable those two messages? (read arrow and orange arrow in the attached image).
Please notice that I don't want to disable PHPCS. I only want to turn off those annoying messages.
I was unable to find it out by myself because I don't even know how those messages are called. Certainly not 'popups', nor 'status bar'
Best regards
Nicolas
Answering my own questions, thanks to the help of the PHPStorm Support team, Vladimir Luchansky (perhaps you need to create an account to see the thread):
To disable breadcrumbs: Go to File->Settings->Editor->General->Appearance, and untick the option Show HTML Breadcrumbs. Then restart the IDE
To disable the PHPCS messages without disabling PHPCS itself: Well, that option is not available in PHPStorm 9. It will be available for a future release. According to Vladimir, a developer is working on it. In order to make this request to go up in the future request list, the request needs to get as much 'votes' as possible. So, if you are interested in this feature to be ready ASAP, please vote up here.
Best,
Nicolas
I don't believe there's any mechanism for suppressing those phpcs: Too many messages per file alerts. As an alternative solution, you could give this work-around a try:
Clone your current inspection profile via Preferences > Editor > Inspections. Name the new one "Strict (with phpcs)". Then, choose your old inspection profile from the Profile: dropdown box (thus, reverting your project's default inspection profile to your old one). Rename it to "Weak (without phpcs)" and disable phpcs for that particular profile by unchecking the PHP > PHP Code Sniffer validation option.
From this point forward, phpcs inspections (and related alerts, like the one you're concerned about) won't come into play as you're editing your files. However, whenever you do want to inspect one of your files using PHP Code Sniffer, you can do so easily via Code > Inspect Code > Inspection Profile > Strict (with phpcs)
Hope this helps!
Does anyone know of an MSSCCAPI provider for Mercurial? I'd like to try out Kiln/Mercurial with PowerBuilder, but the PowerBuilder IDE only recognizes MSSCCAPI providers (which is not the same as MS SCC Package API) and the only one I can find is the original version of HgSccPackage.
I've contacted the developer and he has stated that he will not switch back from the Package to the regular API so that option leaves me with no upgrade path. This question was asked in July of 2010 with only the response that I have already mentioned. I'm hoping there's been something new since then. Thanks!
I don't have enough rep to post this as a comment to the question.
Maybe your PowerBuilder source control methodology is holding you back. Do you control the PB objects inside of the PBLs? Or do you control *.sr? (PB Export) files, maybe using PowerGen to synchronize them into the PBLs?
At work, a set of PBLs is published to programmers by the Build Manager at every build. This avoids having to pay one PowerGen license per programmer for them to sync up (which can take 5-40 minutes depending on the number of changes and the app size). You need just one license for the build server.
One caveat is that programmers need to understand the flow correctly so not to lose code or cause regressions, but a good inspection of the TortoiseHg diff window should allow to catch most problems before committing.
When I close a file in PhpStorm, it saves the file automatically.
How can I change it to ask me "Do you want do save the file before closing?"
Autosave settings are under File | Settings | General.
http://www.jetbrains.com/phpstorm/webhelp/saving-and-reverting-changes.html
While autosaving is handy for local, non-vital projects, this can be disastrous in a live project, where every change needs to be checked first.
Update: In recent versions, they have been moved to File | Settings | Appearance and Behavior | System Settings | Synchronization
There is no way to disable automatic save completely, but you can partially control this behavior:
Note that those are optional autosave triggers, and you cannot turn off autosave completely.
The answer below from #Owen is not correct, since there is no way to completely turn off automatic save in the IDE.
Automatic save is the core design feature, we believe that it's much more efficient and productive than manual save. There is no way to disable this behavior or enable any confirmations, quoting the FAQ (WebStorm is based on IntelliJ IDEA platform, so the same applies):
Because IntelliJ IDEA has the ability to change so many files
simultaneously in large refactoring actions, and change them without
ever opening them, single file saves don't make very much sense. In
recognition of this, IntelliJ IDEA reserves the right to save any
of your files literally whenever it wishes. It's actually quite nice
to never have to worry about your file's save statuses, once you get
used to it.
"What if I don't like some changes I made, and want to
roll them back?", I hear you say. Well, for that IntelliJ IDEA
includes this amazing feature called the Local History.
Every time it saves your files, IntelliJ IDEA actually saves a diff of
your file from it's previous state, and saves that as well. You can
see the entire edit history of your files (going back some
configurable number of days), see the changes you've made, and roll
back any change. It rules triumphantly, and more than makes up for the
temporary disorientation caused by lack of single-file save.
This feature has been in IntelliJ IDEA for a decade, and now even Apple has recognized that it's better than manual saving and implemented it in Mac OS Lion.
Just my two cents to a similar issue:
I had PhpStorm seemingly auto-save on every keypress, which was making my live reload go mad. Turns out, I had checked Recompile on changes under Settings -> Languages & Frameworks -> TypeScript.
Hope this can help someone.
I just got a mail saying that I have to change a config value at 2009-09-01 (new taxes). Our normal approach for this would be to to awake at 2009-08-31 at 23:59 and then just change the value manually. Which not is a big problem since this don't happens to often. But it makes me wonder how other people handle issues like this.
So! How do you handle date specific config changes?
(We are working in asp.net but I don't think this has to be language specific)
Br
Carl Bergquist
I'd normally store this kind of data in a database table like this
Key, Value, EffectiveFrom, EffectiveTo
-----------------------------------------
VAT, 15.0, 20081201, 20091231
VAT, 17.5, 20100101, NULL
I'd then use the EffectiveFrom and EffectiveTo dates to chose the value that is effective at the given time. If the rate is open ended then the effecive to could either by NULL or 99991231.
This also allows you to go back without having to change the config. E.g. if someone asks you to recalculate the tax for the previous month before the rate change.
In linux, there is a command "at" for batch execution.
See "man at" for details.
To be honest, waking up near the time and changing it seems to be the simplest and cheapest approach. All of the technical solutions are fine, but it depends where you work.
In our environment it would be cheaper and simpler to get someone to wake up and make the change than to redevelop the functionality of a piece of software that already works. It certainly involves less testing, development overhead and costs which means we would tend to solve the problem as you do, manually.
That depends totally on the situation and the technology.
pjp's idea is good, if you get your config from a database, or as metadata to define the valid time for whole config sets/files.
Another might be: just prepare a new configfile with the new entries and swap them at midnight (probably with a restart of the service/program) whatever.
Swapping them would be possible with at (as given bei Neeraj) ...
If timing is a problem you should handle the change, or at least the timing of the change on the running server (to avoid time out of synch problems).
We got same kind of problem some time before and handled using the following approach.
this is suitable if you are well known to the source that orginates the configuration changes..
In our case, the source exposed a webservice (actualy a third party) which will return a modified config details. And there is a windows service running on our server which keeps on polling the webservice and will update the configuration file if there is any change.
this works perfectly in our case..
You can make use of this approach by changing the polling webservice part to your source of config change (say reading changes from some disk path). But am not sure how this is possible reading config changes from email.
Why not just make a shell script to swap out the files. run it in cron and switch the files out a minute before and send an alert text if NOT successful and an email if successful.
This is an example on a Linux box but I think you get the point and can do this on a Windows box.
Script:
cp /path/to/old/config /path/to/backup/dir/config.timestamp
cp /path/to/new/config
if(/path/to/new/config exsits) {
sendSuccessEmail();
} else {
sendPanicTextAlert();
}
cron:
59 23 31 8 * /path/to/script.sh
you could test this as well before hand just point to some dummy directories and file
I've seen the hybrid approach. Instead of actually changing the data model to include EffectiveDate/EndDate or manually changing the values yourself, schedule a script to change the values automatically. Also, be sure to have a solid test plan that will validate all changes.
However, this type of manual change can have a dramatic impact on reporting. If previous transactions join directly to the tables being changed, numbers in historical reports could change in a very bad way. There really is no "right" answer.
If I'm not able to do something like pjp's solution, I'd use either a scheduled task or a server job to update it automatically at the right time.
But...I'd probably still be awake checking it had worked.
Look the best solution would be to parameterise your config file and add things like when a certain entry should be used from. This would negate the need for any copying or swapping of files and your application would simply deal with it. (That goes for a config file approach or a database)
If you cannot change the current systems and you have to go with swapping the config files, then you also have two options:
Use a scheduled task to kick off a batch job or even a VBScript or PowerShell script (which ever you feel comfortable with) Make sure you set up the correct credentials to be able to do this at the middle of the night and you could also add some checking and mitigation into this approach.
Write a windows Service that does this for you. Here you have all the flexibility you need. Code it to do whatever it needs to do, do all the checks you need to (so that you can keep sleeping rather than making sure it actually worked) etc, etc. You service would then even take care of the scheduling aspect and all will be good. Here you could use xml DOM object and xPath and not replace the file, but simply update the specific entries as required.
Remember that any change to the config file would cause your site to restart, so make sure you take care of all the other housekeeping stuff that this could cause. (Although this would be exactly the same if you where sitting there in the middle of the night copying file around)
On a wiki-style website, what can I do to prevent or mitigate write-write conflicts while still allowing the site to run quickly and keeping the site easy to use?
The problem I foresee is this:
User A begins editing a file
User B begins editing the file
User A finishes editing the file
User B finishes editing the file, accidentally overwriting all of User A's edits
Here were some approaches I came up with:
Have some sort of check-out / check-in / locking system (although I don't know how to prevent people from keeping a file checked out "too long", and I don't want users to be frustrated by not being allowed to make an edit)
Have some sort of diff system that shows an other changes made when a user commits their changes and allows some sort of merge (but I'm worried this will hard to create and would make the site "too hard" to use)
Notify users of concurrent edits while they are making their changes (some sort of AJAX?)
Any other ways to go at this? Any examples of sites that implement this well?
Remember the version number (or ID) of the last change. Then read the entry before writing it and compare if this version is still the same.
In case of a conflict inform the user who was trying to write the entry which was changed in the meantime. Support him with a diff.
Most wikis do it this way. MediaWiki, Usemod, etc.
Three-way merging: The first thing to point out is that most concurrent edits, particularly on longer documents, are to different sections of the text. As a result, by noting which revision Users A and B acquired, we can do a three-way merge, as detailed by Bill Ritcher of Guiffy Software. A three-way merge can identify where the edits have been made from the original, and unless they clash it can silently merge both edits into a new article. Ideally, at this point carry out the merge and show User B the new document so that she can choose to further revise it.
Collision resolution:
This leaves you with the scenario when both editors have edited the same section. In this case, merge everything else and offer the text of the three versions to User B - that is, include the original - with either User A's version in the textbox or User B's. That choice depends on whether you think the default should be to accept the latest (the user just clicks Save to retain their version) or force the editor to edit twice to get their changes in (they have to re-apply their changes to editor A's version of the section).
Using three-way merging like this avoids lock-outs, which are very difficult to handle well on the web (how long do you let them have the lock?), and the aggravating 'you might want to look again' scenario, which only works well for forum-style responses. It also retains the post-respond style of the web.
If you want to Ajax it up a bit, dynamically 3-way merge User A's version into User B's version while they are editing it, and notify them. Now that would be impressive.
In Mediawiki, the server accepts the first change, and then when the second edit is saved a conflicts page comes up, and then the second person merges the two changes together. See Wikipedia: Help:Edit Conflicts
Using a locking mechanism will probably be the easiest to implement. Each article could have a lock field associated with it and a lock time. If the lock time exceeded some set value you'd consider the lock to be invalid and remove it when checking out the article for edit. You could also keep track of open locks and remove them on session close. You'd also need to implement some concurrency control in the database (autogenerated timestamps, perhaps) so that you could make sure that you are checking in an update to the version that you checked out, just in case two people were able to edit the article at the same time. Only the one with the correct version would be able successfully check in an edit.
You might also be able to find a difference engine that you could just use to construct differences, though displaying them in a wiki editor may be problematic -- actually displaying the differences is probably harder than constructing the diff. You'd rely on the versioning system to detect when you needed to reject an edit and perform a diff.
In Gmail, if we are writing a reply to a mail and someone else sends a reply while we are still typing it, a popup appears indicating that there is a new update and the update itself appears as another post without a page reload. This approach would suit your needs and if you can use Ajax to show the exact post with a link to diff of what was just updated while User B is still busy typing his entry that would be great.
As Ravi (and others) have said, you could use an AJAX approach and inform the user when another change is in progress. When an edit is submitted, just indicate the textual differences and let the second user work out how to merge the two versions.
However, I'd like to add on with something new you could try in addition to that: Open a chat dialog between the editors while they're doing their edits. You could use something like embedded Gabbly for that, for instance.
The best conflict resolution is direct dialog, I say.
Your problem (lost update) is solved best using Optimistic Concurrency Control.
One implementation is to add a version column in each editable entity of the system. On user edit you load the row and display the html form on the user. A hidden field gives the version, let's say 3. The update query needs to look something like:
update articles set ..., version=4 where id=14 and version=3;
If rows returned is 0 then someone has already updated article 14. All you need to do then is how to deal with the situation. Some common solutions:
last commit wins
first commit wins
merge conflicting updates
let the user decide
Instead of an incrementing version int/long you can use a timestamp but it's not suggested because:
retrieving the current time from the JVM isn't necessarily safe in a clustered environment, where nodes may not be time synchronized.
(quote from Java Persistence with Hibernate)
Some more info at the hibernate documentation.
At my office, we have a policy that all data tables contain 4 fields:
CreatedBy
CreatedDate
LastUpdateBy
LastUpdateDate
That way there is a nice audit trail on who has done what to the records, at least most recently.
But most importantly, it becomes easy enough to compare the LastUpdateDate of the current or edited record on the screen (requires you to store it on the page, in a cookie, whatever, with the value in the database. If the values don't match, you can decide what to do from there.