SuSE version is SuSE10 SP2
If I want to manage some service, for example, named, I have several choices.
choice 1. /etc/init.d/named status
choice 2. service named status
choice 3. rcnamed status
These 3 commands have the exactly same return. I understand choice 1 and 2, but how does rc-prefix work in choice 3? anybody know this?
The third one is a SuSE-ism which is typically a symlink to the appropriate /etc/init.d file for historical reasons. (SuSE took its service management originally from BSD-influenced OSF/1, and still retains some of those behaviors. I haven't checked to see if SuSE 10 still has the OSF/1-ish /sbin/init.d symlink as well as the ones you mentioned.)
Related
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
i want to know is it possible to increase the number of build queue in Hudson?
i m using Hudson version 1.395.1
Currently only 2 queue are provided but in my case, i have 6 environment managed with hudson. so i need to have more than 2 build queue number.
We only have a Jenkins but it should be similar. In the configuration menu there is an option almost at the top. Should be called something like "number of build processes". Can't say exactly because our Jenkins is also German ;-)
Sorry for the unspecific answer but maybe it 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.
What is the best method to determine the version number I should use for a software or component? Is there a general rule to set version numbers?
I'm pretty sure it is a basic question but I didn't find anything useful after searching a while.
Microsoft have a convention of:
[major].[minor].[revision].[build]
Or follow Jeff's versioning system.
I've been doing this as an interim until I find a better solution. I don't build many large applications, mostly reports and smaller macros, but it's still important for me to keep track of changes and versions.
[Current year].[Current month].[Current day]
FileName 9.7.17.rpt for example.
It works for me and my boss, and it gives a value which you can compare to today's date to see how old the file is. I also keep a changelog.txt file in the same folder as the most current version and it keeps track of all the changes from the previous versions. I also keep track of all versions in a version control page on each projects tab in OneNote.
Thanks for the answer. I'll also throw in how I store the projects for giggles.
Every project gets its own folder. Inside that folder I'll have 4 main items that help me keep track of what's going on in the project.
An old versions folder
A folder for any reference material I might need for the project
The actual project file
And the changelog
That tree will look something like this.
Project X
Old versions
X Report 9.4.12.rpt
X Report 9.5.3.rpt
X Report 9.7.20.rpt
Reference
SQL calls.txt
Client list.txt
Procedures.doc
X Report 9.7.29.rpt
X Report changelog.txt
This way of keeping track of my work really cuts down on the amount of time that I need to spend documenting anything and organizes it in a standard way so if my boss needs to grab something I've worked on, even he knows exactly what everything means and where it is.
For storing multiple projects in my network folder I have these folders.
Inbox
Projects
#Archived Projects
Current Project 1
Current Project 2
Current Project 3
Reference
Inbox is where I toss random things to process later, or a folder where my boss can throw something I'm going to need for a later project. The Projects folder contains all the projects I'm currently working on, and then when I'm done or they no longer become a current priority, they get tossed in #Archived Projects. Reference is a folder for general job reference material, like policies and procedures, phone lists, org charts, fire escape plans. I may never use them, but it's comforting to have a place to put that kind of stuff as opposed to digging through old email.
This is a very common question. Are you sure you searched around? Wikipedia has a good article on software versioning.
Or, you can follow Ubuntu's convention of using year and month.
For example, release on April 2009 would be:
v9.04
Do it like Donald Knuth does with TeX---its version converges to π with each release and will in fact become π when he dies.
Since version 3, TeX has used an
idiosyncratic version numbering
system, where updates have been
indicated by adding an extra digit at
the end of the decimal, so that the
version number asymptotically
approaches π. This is a reflection of
the fact that TeX is now very stable,
and only minor updates are
anticipated. The current version of
TeX is 3.1415926; it was last updated
in March 2008.
from Wikipedia
A common scheme seems to be to use [major].[minor].[revision]. Where the major version number increments on large/major feature changes or rewrites (or stays 0 as long as you didn't reach a stable version, although many open source projects never get past 0 here), minor version number increases on minor changes, such as a collection of bugfixes, an added small feature and the like. revision increments with each build and reflects the smallest granularity of tracking your exact version. Things like small fixes, etc. get rolled into this, usually.
Usually the first number are major changes/major releases, the second number are used when minor features and bug fixes are added, and the third number is used for minor bug fixes and revision numbers.
Ex. 1.0.0
Depends on a lot of things.
If you are doing .Net work, you can have the system keep track of version numbers for your .dlls and .exe files automatically.
We frequently use the subversion revision as part of our version number. We use a system like:
major.minor.svn-version
We increment the major/minor manually based on internal decisions, and have the svn-version propagate to distinguish builds.
The most important thing is that version numbers make sense to your users.
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)