Since there is no GUI option to edit the default starting day of the week in the gnome calendar, how can one change it from Sunday to Monday?
Step by step:
Find out what locales you have installed via
locale -a
For me I only had en_US.utf8 which makes weeks start from Sunday. If you have another locale that makes weeks start from Monday (such as en_GB.utf8) you can skip the next step
Edit /etc/locale.gen so that a locale that has weeks that start from Monday is also uncommented (such as en_GB.utf8). Save and generate the locale with
locale-gen
Now that you have the appropriate locale installed (check with locale -a to confirm it's there) open /etc/locale.conf, quite likely you'll only have one line at the top to the effect of LANG=<your_original_locale>.
Add an entry underneath it for LC_TIME with your newly installed locale (for example LC_TIME=en_GB.UTF-8). Save and reboot, changes should take effect on startup.
Related
I'm trying to compare and merge MySQL WorkBench files in SourceTree, and in order to do so I created a small shell script that extracts the content of the .mwb file and strips some useless counters from the XML file inside it.
Then I added this line to .gitconfig in the project's root:
[diff "mwbdiff"]
textconv = mwb-diff
and this in the .gitattributes:
*.mwb diff=mwbdiff
Now, if I change something on a .mwb, then "git diff" on console shows the correct differences, and SourceTree does it, too:
The problem is that if I try to do the same on already committed versions, I get nothing:
Same result if I try to merge. I still get the right output if I try to run GIT from the console like this:
git diff develop feature/four -- test.mwb
but if I try to merge, then I get unsolved conflicts and I don't know how to proceed.
I also tried to move the .gitattributes and .gitconfig changes into the global variables, and it actually works in the console, but it didn't help SourceTree.
I suspect it has something to do with the binary preview in SourceTree (Mac version), if I could disable it...
What am I missing? How can I solve this problem?
I think that this is not supported.
So to avoid calling git diff when it will ultimately just produce no output, SourceTree pre-detects whether files are binary or text on the disk, identified by whether in a quick sample of the initial chunk of the file contains a couple of binary zero's in succession. I can only assume that the odt formats include this sequence, so SourceTree treats them as binary. On Mac we have a binary preview pane which displays before/after of supported binary files but we haven't ported that to Windows yet.
At the moment we don't support your case and may not add it in the near future, because it's a pretty rare thing to do and most people would just see a performance penalty when git diff fails and we then fall back on other techniques. We'll keep this logged for possible future support.
Source: JIRA - textconv diff not generated
So in other words, SourceTree specifically avoids calling git diff for files that SourceTree considers to be binary. That means that any textconvs don't get called at all.
The only way to work around this would be to trick SourceTree into thinking that your file isn't binary. Which is probably not feasible.
I've made unwanted changes to several files recently. Is it possible to revert them based on the time (for example revert all changes made in last 10 minutes)
Option 1: Rollback or strip
In case you already commit (and not pushed) some of the unwanted changes, it is easy:
$ hg strip <firts-unwanted-revision>
This requires the mqstrip extension to be enabled.
Alternatively check if the rollback command is sufficient for your case.
Option 2: Revert selected files only
Otherwise you can only revert files to the state of the last commit. Mercurial (as Git, SVN, and most other version control systems) only tracks changes when you commit. Everything in between is out of Mercurial's control. That's why it is generally best to commit early and often.
However, you could make use of the modification time of your files and only revert those that have been touched in the last 10 minutes. Be aware that this reverts all changes per file, i.e. also changes made in these files more than 10 minutes ago. It only safes your correctly edited files where the last change has been more than 10 minutes ago.
$ hg revert <files-touched-within-last-10-minutes>
On Unix systems, you get the list of all files modified within the last 10 minutes using the find command:
$ find -mmin -10
Option 3: Commit good changes, discard bad ones
Finally there is a 3rd option which works good when your bad changes did not overwrite good changes but exist next to them. Here a good strategy is to
only commit the good changes (using the record or crecord command), and then
revert all remaining changes (e.g. with hg up -r . -C)
The HG-Book has more hints on dealing with unwanted changes.
We use Jenkins for doing incremental builds of our project on each commit to the SCM. We would like to get separate builds for every single commit. However, the naive approach (setup SCM and use post-commit hooks to trigger a build) exhibits problem in the following scenario:
Build is triggered.
While build takes place (it can take up to several minutes) two separate commits to the SCM are made by two developers.
One new build is triggered. It receives changes from both of the commits, made during previous build.
This "race condition" complicates finding which one of the commits has broken the build/introduced warnings.
The currently employed solution is checking for changes in one job ("scheduler job") and triggering another job to do the actual checkout and build.
Are there any proper solutions to this problem?
Not yet, there's a Feature Request covering this kind of build, but it's still open: Issue 673
Maybe it misses the point, but we have a pretty nice build process running here.
We use git as our source control system
We use gerrit as our review tool
We use the gerrit trigger to run builds on our jenkins server
We check for changes on the develop branch to run jenkins when a changeset is merged
In short the ideal developer day is like this
developer 1 stars a new branch to do his changes, based on our main develop branch
The developer 1 commits as often as he likes
developer 1 thinks he finished his job, he combines his changes into one change and pushes it to gerrit
A new gerrit change is created and jenkins tries to build exactly this change
When there are no errors during the build, a review is made on this change
When the review is submited, the changeset is merged into the develop branch of the main repository (No change is merged into the develop branch, without review)
Jenkins builds the merged version to be sure, that there are no merge errors
no developer 2 joins the party and tries to do some work
the process is exactly the same both start working, in there branches. Developer 1 is faster and his changes are merged into the develop branch. Now, before developer 2 can publish his changes he has to rebase his changes on top of the changes made by developer 1.
So we are sure, that the build process is triggered for every change made to our codebase.
We use this for our C# development - on windows not on linux
I don't believe what you'd like to do is possible. The "quiet period" mentioned by Daniel Kutik is actually used to tell Hudson/Jenkins how much time to wait, in order to allow other commits to the same project to be picked up. Meaning -- if you set this value to 60 seconds and you've made a commit, it will wait for a minute before starting a new build, allowing time for other commits to be picked up as well (during that one minute).
If you use the rule "NO COMMIT on a broken build‏" and take it to it's logical conclusion, you actually end up with "No commit on a broken build or a build in progress", in which case the problem you describe goes away.
Let me explain. If you have two developers working on the same project and both of them try to commit (or push if you're using DVCS). One of them is going to succeed and and they other will fail and need to update before the commit.
The developer who had to do the update knows from the commit history, that the other commit was recent and thus a build in progress (even if it hasn't checked out yet). They don't know if that build is broken yet of not, so the only safe option is to wait and see.
The only thing that would stop you from using the above approach is if the build takes so long, in which case you might find that your developers never get a chance to commit (it's always building). This is then a driver to split up your build into a pipeline of multiple steps, so that the Post Commit job takes no more than 5 minutes, but is ideally 1 minute.
I think what might help, is to set the Quiet Period (Jenkins > Manage Jenkins > Configure System) to 0 and the SCM Polling to a very short time. But even during that short interval there could be two commits. As of now Jenkins does not have the feature to split build into single builds on multiple SVN commit.
Here is a tutorial about that topic: Quiet Period Feature.
As pointed out by someone in Issue 673 you could try starting a parametrized build with the parameter being the actual git commit you want to build. This in combination with a VCS commit hook.
I've set up Hudson so it performs a build every hour. But I'd like it to wait a certain amount of time whenever there is "recent" checkin activity, in case there is more code about to be checked in related to this.
So I've set up the poll SCM option and the quiet period option but the build always seems to wait for the quiet period whenever there is an SCM change.
So I just wanted to know whether the SCM polling and quiet period can be used together in Hudson or is the quiet period superfluous when using a schedule.
AFAIK, the quiet period should persist regardless of whether it starts by SCM change or by schedule. At least that's the behaviour I have noticed on our build system.
It turns out our slaves spend a considerable amount of time moving the archived artifacts back to the master Hudson node. It at least triples the duration of the build. It would be nice if there would be a way to prevent it. However, setting the maximum number of builds to keep doesn't have an influence at all. Is there another way to prevent sending the results back to the central Hudson master?
Note that I actually don't have the archive artifacts option checked. However, the slave is still 'archiving' whatever it finds to the master:
[HUDSON] Archiving .../pom.xml to .../pom.xml
[HUDSON] Archiving .../...-0.1.3-SNAPSHOT.jar to .../...-0.1.3-SNAPSHOT.jar
... with the second path in every line always being a location on the master. Is this a bug? Is there a workaround?
Maven jobs have an option for not archiving artifacts in the advanced options of the Maven section - that is, separate from the "Archive Artifacts" publisher. By default, the Maven jobs will archive the Maven artifacts of a module automatically, regardless of the "Archive Artifacts" publisher settings. The advanced option for Maven projects was added a couple months ago, if I remember correctly.
It sounds that you don't need the archived artifacts at all. So check the archive artifacts option for your jobs. If it is unchecked and it still copies the artifacts to the master to scrap them right away, open a bug report with Hudson.
If you need some, play around with the advanced options for archive artifacts. They offer an include as well as an exclude option.