I have some files that use the autoproperty $Date of SVN.
When some colleagues in France do a checkout of the repository, the date is in French. When they do the verification of checksum, these files are KO because of this difference of format for the date.
Note: we are using Windows and our client of choice is TortoiseSVN but are open to use command line clients.
Question 1: Is there any way to force the format for the date during the checkout?
We tried the following:
Setting "English" in Tortoise SVN
Setting environment variable LANG to EN_US and doing a checkout with both TortoiseSVN and svn commandline
None of these solutions is working.
Question 2: Would the time zone impact the date in the header as well?
Thanks
NB: This is the header of our source code, for what it matters.
/*==============================================================================================
* FILENAME : Source.h
* VERSION : $Revision: 85911 $
* MODIFICATION DATE : $Date: 2015-06-12 18:26:22 +0800 (Fri, 12 Jun 2015) $
*============================================================================================*/
A1: I don't know, how to manipulate locale-setting in Windows in easy and automated style - inspired by this old answer in Subversion maillist - (better to ask it SU) and can suggest now only dirty hack: import reg-files for FR and EN locales before and after checkout (how to prepare: switch to FR in Control Panel, save Current Control Set part of registry, return to EN, save CCS again, leave in .reg only mutable part), checkout in bat-file only (change locale around checkout)
A2: Sad, but yes
$Date: 2015-06-19 19:45:22 +0500 (Пт, 19 июн 2015) $
inserts not only language-specific date (trailing part), but also TZ of client
1.8.*-specific solution: you can create and use replacement for $Date keyword, which use UTC-time instead of local (as $Id do for time-part now) with %d variable it it
>svn pl -v file.txt
Properties on 'file.txt':
svn:keywords
Author Date Id Revision URL Header IntDate=%d
and IntDate will expand location-independent
$IntDate: 2015-06-19 14:45:22Z $
Related
Quick intro: In Mercurial there are two different ways to numerically refer to a changeset.
First, there's the node ID hash. It is global and functions like a git commit hash. It consists of 40 hexadecimal digits.
Second, there's the local revision number. It is a decimal number that starts at 0 and counts up. Unlike the node hash, this is local, meaning the same changeset can have different local revision numbers in two different repos. This depends on what other changesets are present in each repo and depends even on the order each repo received their changesets.
A revision can be specified numerically to Mercurial as a local revision number, a full 40-digit hash, or "a short-form identifier". The latter gives a unique prefix of a hash; that is, if only one full hash starts with the given string then the string matches that changeset.
I found that in certain cases, Mercurial commands (such as hg log with an -r switch), given plain decimal numbers, will match some revision even though there aren't enough local revisions for the given number to match as a local revision number.
Here's an example I constructed after coming across such a case by chance:
test$ hg --version
Mercurial Distributed SCM (version 6.1)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2022 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test$ hg init
test$ touch a
test$ hg add a
test$ hg ci -d "1970-01-01 00:00:00 +0000" -u testuser -m a
test$ touch b
test$ hg add b
test$ hg ci -d "1970-01-01 00:00:00 +0000" -u testuser -m b
test$ hg log
changeset: 1:952880b76ae5
tag: tip
user: testuser
date: Thu Jan 01 00:00:00 1970 +0000
summary: b
changeset: 0:d61f66df66f9
user: testuser
date: Thu Jan 01 00:00:00 1970 +0000
summary: a
test$ hg log -r 2
abort: unknown revision '2'
test$ hg log -r 9
changeset: 1:952880b76ae5
tag: tip
user: testuser
date: Thu Jan 01 00:00:00 1970 +0000
summary: b
test$
As is evident, hg log -r 9 matches a changeset even though there aren't that many changesets to match the 9 as a local revision number.
The question: Why is this? Additionally, how can we avoid matching a nonexistent local revision number?
This is due to how Mercurial parses revision specifiers. Here's how Olivia Mackall explains it in a mail from 2014:
Here is a hexadecimal identifier:
60912eb2667de45415eff601bfc045ae0fe8db42
See how it starts with 6? If you ask for revision 6, Mercurial will:
a) look for revision 6
b) if that fails, look for a hex identifier starting with "6"
c) if we find more than one match, complain
d) if we find no matches, complain
e) we found one match: success!
That is, if hg log -r 9 doesn't match any local revision number (because there are less than ten changesets in the repo), Mercurial next will match a node hash that happens to start with a 9.
To avoid this ambiguity, she responded that one should use hg log -r 'rev(9)' to match only local revision numbers, and hg log -r 'id(9)' to match only prefixes or full hashes.
In the documentation on revsets, these predicates are listed as:
"id(string)"
Revision non-ambiguously specified by the given hex string prefix.
And:
"rev(number)"
Revision with the given numeric identifier.
Unfortunately, both this page and the help page on revisions do not (as of version 6.1) explicitly point out the ambiguity between numbers that can match either as local revision numbers or node hash prefixes. The 2014 mailing list thread I quoted does contain suggestions to clarify this but it appears nothing came off it.
Additionally, here is a changeset message in which I explained the entire affair and how it came to affect the operation of a script of mine:
fix to use 'rev(x)' instead of just x to refer to local rev number
The revsets syntax to unambiguously refer to a local revision
number is to wrap the number in rev(). Without this, a number
that doesn't exist (eg -r 2) may be misinterpreted to refer to
a changeset that has a node hash starting with the requested
number.
In our case this bug happened to act up after the revision on at
2022-04-02 16:10:42 2022 Z "changed encoding from cp850 to utf8"
which the day after it was added was converted as the second
(local revision number 1) changeset from the svn repo. The
particular hg convert command was:
hg convert svn-mirror DEST \
--config hooks.pretxncommit.checkcommitmessage=true \
--config convert.svn.startrev=1152
This created a changeset known as 1:2ec9f101bc31 from that svn
revision. Lacking a local revision number 2, the -r 2 picked up
this changeset because its hash started with the digit "2".
Tnus the NEWNODE variable received the changeset hash for this
changeset. Because our hg rebase command is configured to keep
empty changesets, the changeset got added atop its already
existing copy in the destination repo.
Ever since the akt.sh script would pick up the wrong revision
number from the destination repo and abort its run with the
message indicating "Revisions differ!".
I have a project that will require reading a local repo and collecting the diff from the most recent commit and the one before it. I then need to do additional work with those diffs (add to an existing log file, make available for tech writers to edit existing API docs with the changes - might Slack them or API into Jira and build a ticket (like that option as it leaves a trail).
I can do the yeoman level work in an AppleScript, calling shell scripts when needed then parsing the data, and passing the cleaned data to the various applications/sites I need to. But other, less technical people will also be using this app and it would be nice to give them a simple UI to work with.
Anyway, after much digging through the Google, SO and other sources I was able to get a MacOS app working that can call an AppleScript and now I've run into a wall...
I can run this AppleScript from Script Editor and it works fine:
set strGitLog to do shell script "cd ~/Desktop/xxxxxx/Projects/UnifiedSDK/Repo/xxxxxx && git log -p -- file1.html"
"commit c39c6bb004d2e104b3f8e15a6125e3d68a5323ef
Author: Steve <xxxxxx#xxxxxx.com>
Date: Tue Oct 22 15:42:13 2019 -0400
Added deprecation warning to file1
diff --git a/file1.html b/file1.html
index b7af22b..9fdc781 100644
--- a/file1.html
+++ b/file1.html
## -51,6 +51,8 ##
<h2>Class Description</h2>
<p style=\"margin-bottom:10px;\">This is the description of the class</p>
+ <p style=\"margin-bottom:10px;\">Warning: This class is scheduled to be deprecated.</p>
+
<h3>Arguments:</h3>
<p style=\"margin-bottom:10px;\">These are the arguments that the class accepts</p>
...
but, if I place this script within a MacOS application:
script gitMessenger
property parent : class "NSObject"
to readMessage()
set strGitLog to do shell script "cd ~/Desktop/xxxxxx/Projects/UnifiedSDK/Repo/xxxxxx && git log -p -- file1.html"
log strGitLog
end readMessage
end script
I get this error message in the log:
fatal: Unable to read current working directory: Operation not permitted (error 128)
Which after checking seems to be a Git permissions error. If I pwd I am pointing to the right directory:
/Users/xxxxxx/Library/Containers/xxxxxx.GitMessenger/Data/Desktop/xxxxxx/Projects/UnifiedSDK/Repo/xxxxxx
and that directory has git initiated on it:
and it has permission for read/write to everyone. So I am a little at a loss right now how to get this to work. Any help or suggestions would be appreciated.
If I have two tags named 2.0 and 2.1, how do I find the changeset messages between the two? I'm trying to find to a way to use HG make release notes and list the different messages associated with the commits.
Example Changeset:
changeset: 263:5a4b3c2d1e
user: User Name <user.name#gmail.com>
date: Tue Nov 27 14:22:54 2018 -0500
summary: Added tag 2.0.1 for changeset 9876fghij
Desired Output:
Added tag 2.1 for changeset 67890pqrst
Change Info...
Added tag 2.0.1 for changeset 9876fghij
Change Info...
Added tag 2.0 for changeset klmno12345
Preface
"Any challenge has a simple, easy-to-understand wrong decision". And Boris's answer is a nicest illustration for this rule: "::" topo-range will produce good results only in case of pure single-branch development (which is, in common, The Bad Idea (tm) anyway)
Face
Good solution must correctly handle complex DAGs and answer on question "New changesets included in NEW, missing in OLD (regardless of the nature of occurrence)"
For me it's "only()" functions in revsets with both parameters
"only(set, [set])"
Changesets that are ancestors of the first set that are not ancestors
of any other head in the repo. If a second set is specified, the
result is ancestors of the first set that are not ancestors of the
second set (i.e. ::set1 - ::set2).
hg log -r "only(2.1,2.0)"
maybe for better presentation powered by predefined style "changelog"
hg log -r "only(2.1,2.0)" -s changelog
or custom style|template
You'll want to use a revset to select all changesets between two tags, for example: 2.0::2.1 will likely do the trick. You can validate the selected changesets by running: hg log -G -r '2.0::2.1'. (See hg help revset for more information about revsets).
Once you have the right selected changesets, you can now apply a template to retrieve only the needed information. For example if you only want the first line of changeset description, you can do hg log -r '2.0::2.1' -T '{desc}\n' for the whole description or hg log -r '2.0::2.1' -T '{desc|firstline}\n' only for the first line of each changeset description.
If you want to add even more information, hg help template is your friend.
I have a Subversion repository, which is a mirror of a subtree accessable by our team.
The svnadmin dump was created with a account with limited access to the source repository.
The mirror was than initalised with svnadmin load.
svnadmin load repo < svndump
svn propset --revprop -r0 svn:sync-from-uuid af407c0b-a50a-0410-b304-fd27f8ee8df8 %dstrepo%
svn propset --revprop -r0 svn:sync-last-merged-rev 187698 %dstrepo%
svn propset --revprop -r0 svn:sync-from-url %SourceRepo% %dstrepo%
The history contains a great number of revisions without paths and dates.
svnsync sync %dstrepo% %SourceRepo%
Sync Is working
This results in great number of svn revisions looking like this
svn log -vl10 repo
....
------------------------------------------------------------------------
r204669 | ebenneheij | 2014-09-22 12:04:00 +0200 (ma, 22 sep 2014) | 4 lines
------------------------------------------------------------------------
....
r204570 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r204569 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r204568 | (no author) | (no date) | 1 line
Related: How to get the SVN revision number in certain Date or date range
Related: http://manned.org/rsvndump/29eed607
It looks like these empty revisions are there for padding, but they are breaking the option to use a date range for revisions.
I'm trying to validate the last 30 days of commits with
svnadmin verify -r {`date -d '30 days ago' +%F `}:HEAD repo
This fails on the revisions without a date in the revprops.
Failed to find time on revision 191375
Somehow the svnadmin dump and svnsync create empty revisions without date information.
This is causing the error I am seeing.
I tried to drop empty revisions with svndumpfilter --drop-all-empty-revs.
The problem with that solution is that svnsync won't connect anymore.
A solution I see now is to replace svnsync with svnrdump and svndumpfilter with the lastsynchronised revision stored somewhere.
Can I fill in the padded revisions with a date so the date range will work?
Update: added mirroring description
Update2: only revisions with paths visible to me contain dates
Update3: alternative suggestion
Update4: empty revisions for padding do not contain date, how to fill the date?
I have several servers running under centos 6.3 and I faced issue that perl module DateTime treats Europe/Moscow timezone as UTC+3
[ulan#rt-virtual ~]$ perl -MDateTime -e 'print DateTime->now()->set_time_zone("Europe/Moscow"), "\n";'
2013-12-19T11:11:38
but in fact it is UTC+4 and system tools like zdump or date work correctly
[ulan#rt-virtual ~]$ zdump Europe/Moscow
Europe/Moscow Thu Dec 19 12:11:47 2013 MSK
I updated tzdata and DateTime module but it didn't help.
How can I amend this?
Thanks.
Well, DateTime module is doing its magic by following the rules specified in the TimeZone modules specific for each timezone. For Europe/Moscow, the module's is DateTime::TimeZone::Europe::Moscow. The problem is all the files are generated automatically corresponding to the rules existing when a specific version of DateTime module is released.
In this case one very important change - Russia's stopping following DST routines in 2011 - wasn't obviously reflected in that file. So updating - either the whole module or only the relevant TimeZone part - should have fixed the issue.
You can use your systems tzfile(5), using DateTime::TimeZone::Tzfile. Not only does it perform better than DateTime::TimeZone it also removes the need to have redundant data that needs to be in sync.
$tz = DateTime::TimeZone::Tzfile->new('/etc/localtime');
$dt = DateTime->now(time_zone => $tz);