lanchpad.net states that for project Emle - Electronic Mathematics Laboratory Equipment, the current focus of development is the 2.0 series
This is what I have done so far:
Set the launchpad.net project to import from the sourceforge.net project Emle (this actually set the launchpad.net project to mirror the sourceforge.net project rather than just inport the content once)
Examined the launchpad.net project to see that the three commits (#1 - #3) which were done in the sourceorge.net project previousley made it into launchpad.net.
Used bzr to get the launchpad.net project which I did while it was still set for mirroring.
Made three changes and commits using bzr (#4 - #6).
Was unable to see the changes on the launchpad.net site.
Requested the mirroring to be stopped (it did).
Here is an extract from lanchpad.net for project Emle 2.0 series showing that launchpad.net has #1 - #3:
Code for this series
The following branch has been registered as the mainline branch for this release series:
lp:emle - C.W.Holeman II
3 revisions, 3 in the past month.
This shows that #4 - #6 have some kind of problem:
$ bzr missing
Using saved parent location: bzr+ssh://bazaar.launchpad.net/~cwhii/emle/2.0/
You have 3 extra revision(s):
------------------------------------------------------------
revno: 6
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:13:29 -0800
message:
#528096 Corrected setting of paramter value for emleDir to the dir
attribute value of the message element in the lanuage message file,
lang/emle_lang_XX.xml. Minor refactor - Consistently setting the dir and lang
attributes of html, head and body elements.
------------------------------------------------------------
revno: 5
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:08:09 -0800
message:
Minor refactor - improved comment regarding workaround for replacing
html vs head and body elements from index html with lab transformed
XML (to html) document tree.
------------------------------------------------------------
revno: 4
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:04:29 -0800
message:
#529089 #529087 Index file html tag lang attribute corrected and empty link tag changed
How do I get the changes that are in bzr on my system to apply to launchpad.net?
More info:
$ bzr check
Checking working tree at '/home/cwhii/work/lp.emle'.
Checking branch at 'file:///home/cwhii/work/lp.emle/'.
Checking repository at 'file:///home/cwhii/work/lp.emle/'.
checked repository <bzrlib.transport.local.LocalTransport url=file:///home/cwhii/work/lp.emle/> format <RepositoryFormat2a>
6 revisions
83 file-ids
checked branch file:///home/cwhii/work/lp.emle/ format Branch format 7
$ bzr merge
Merging from remembered parent location bzr+ssh://bazaar.launchpad.net/~cwhii/emle/2.0/
Nothing to do.
It turnes out that lp:~cwhii/emle/2.0 is an auto-import branch from svn. You're not allowed to write to import branches, even if you own them, because that would cause confusion when the auto-import robot tries to keep writing to them.
So what I suggest you do here is
1- go to http://launchpad.net/people/+newteam and make an emle-dev team, so that you can later let other people write to this project if you want
2- go to http://code.launchpad.net/~cwhii/emle/2.0/+edit and change the name field to "2.0-import" to "get it out of the way"
3- on your pc, in the branch directory, type "bzr push --remember lp:~emle-dev/emle/2.0"
4- on http://launchpad.net/emle/2.0/+linkbranch enter ~emle-dev/emle/2.0 to indicate this is now the focus of development
hope that helps.
(sorry they're not real links, I don't have enough karma here.)
The poor message here is https://launchpad.net/bugs/543797/
Related
The real problem
I want to apply project level source code formatting to all modified files
Current approach
Use add_custom_target in my top-level CMakeLists.txt file to call a script that applies formatting rules to all files the SCM tool reports as modified:
add_custom_target(Name ALL ${PROJECT_SOURCE_DIR}/../cmake/format_files.bash
)
This rule is before any add_subdirectory calls, because reformatting should take place before all compilation.
Per the documentation:
ALL
Indicate that this target should be added to the default build target so that it will be run every time (the command cannot be called ALL).
When CMake itself runs (like any modification to the CMakeLists.txt files), all is good.
The Symptom
Suppose I perform some spacing-related modification to file Foo.hh (my rules replace tabs with spaces, for example). My build is likely to include something like this:
Scanning dependencies of target Foo
make[2]: Warning: File `projects/foo/src/Foo.hh' has modification time 8.7 s in the future
...
make[2]: warning: Clock skew detected. Your build may be incomplete.
I'm pretty sure it's the source formatting script that somehow runs after dependency scanning (or something like that), modifies Foo.hh, and creates the illusion of clock skew.
What I think the question is
What is the right way to force my build process to assert project standards for source code style prior to building, without potentially creating dependency problems?
Is there a better way to introduce formatting to the build process?
Red Herrings
At first, I thought I was dealing with a true clock skew problem; my development environment is on a VMware VM, and we have had some issues with time in the past, but now I'm 99% sure that all the VMs are using host time. Furthermore, a simple test like this (in the same filesystem as my builds) proves there is no intrinsic clock skew:
$ date ; touch foo ; ls --time-style=+%H:%M:%S -l foo ; date
Thu Jan 17 12:48:59 MST 2019
-rw-rw-r--. 1 1001 1001 0 12:48:59 foo
Thu Jan 17 12:48:59 MST 2019
A key facet of the source code formatting process is that there is no deterministic way to know which files might be modified in the script and which will not. Files that comply with project standards are not touched.
For completeness, here is the script:
#!/bin/bash
# This script is intended to format any modified files to project standards
# Change to the project root
cd $(dirname $0)/..
outfile=format.log
file_list=$( git status --short --untracked-files=all src \
| awk '/^( M|\?\?) .*\.(cpp|hh)/ {print $2}' )
# If we haven't changed any files, exit gracefully
[[ -z $file_list ]] && exit 0
# Format the current working set
echo >> ${outfile}
date '+%Y-%m-%dT%H:%M:%S.%N: ' >> ${outfile}
astyle --project $file_list >>${outfile} 2>&1
This script appends to an output file (I'll probably remove that at some point) that looks like this:
2019-01-17T18:54:20.641765133:
Unchanged src/Foo.cpp
Formatted src/Foo.hh
Unchanged src/Bar.cpp
Based on the discussion at https://discourse.cmake.org/t/cmake-pre-build-command/1083, the answer is "don't do that". Formatting can be a target and building can be a target, but having a build step that modifies the dependencies of another build step (after the dependency tree has been evaluated) is bad.
Instead of formatting my code as part of the build, I added it as a CI check on the build server: if formatting would change the code, the build fails. I also created a pre-commit hook to tell me if my code needs formatting. I don't like hooks that change the code checked in; changed code should always be compiled before commit.
I have a project where I want to split it into 3 experiments, each path with a separate twist to it. Down the road, I will want to revert back to a previous iteration or go back to the original. If I pull from the other branch, will it completely replace my local files with the files form the other branch? To keep both iterations locally, should I just copy and paste the folder?
Also with commenting, what is the standard practice for commiting new updates? Every time I commit -m "new update", it replaces the old one and I can't see the history of commits.
In regards to question about viewing commit history, you can use: git log from your terminal in the project's root directory.
More info here.
From the git-scm webpage linked above:
By default, with no arguments, git log lists the commits made in
that repository in reverse chronological order – that is, the most
recent commits show up first.
If you want to see all the differences, you can use the -p flag like so: git log -p.
A good recommendation from the same webpage is to use this command git log --pretty=format:"%h - %an, %ar : %s" to see the log in a very readable format, something like:
ca82a6d - Scott Chacon, 6 years ago : changed the version number
085bb3b - Scott Chacon, 6 years ago : removed unnecessary test
a11bef0 - Scott Chacon, 6 years ago : first commit
Ok I understand that this is probably not conventional, but that aside: I am using the AssemblyFileVersion as kind of my "Build Name" string. It is formated like this:
' File Version information for an assembly consists of the following four values:
'
' Year
' Month
' Day
' Commit Number for that day
'
' Build Name can either be alpha | beta | hotfix | release
' alpha - is a development buildname with rapid changing API
' beta - is a production build for our beta users
' hotfix - is a production version with a bug fix
' release - is a standard issue production version.
<Assembly: AssemblyVersion("0.8.3")>
<Assembly: AssemblyFileVersion("13.10.24.3")>
<Assembly: AssemblyBuildName("alpha")>
Unfourtunately I am having to adjust the AssemblyInfo.vb EVERY TIME I do a git commit. Now I know GIT actually stores the commits in like a log file several places in the .git directory. My question is: is there anyway to automate this file to read from the git files to see what the year/month/day/commit#ForThatDay and automatically adjust the AssemblyFileVersion (or even a custom Assembly Attribute)?
I would use git describe in order to get an id representing the tag/SHA1 of the current commit, and integrate it in your Assembly file.
v1.0-2-g2414721-DEV
^ ^ ^ ^
| | | \-- if a dirtyMarker was given, it will appear here if the repository is in "dirty" state
| | \---------- the "g" prefixed commit id. The prefix is compatible with what git-describe would return - weird, but true.
| \------------- the number of commits away from the found tag. So "2414721" is 2 commits ahead of "v1.0", in this example.
\----------------- the "nearest" tag, to the mentioned commit.
It is similar to "Automatically versioning Android project from git describe with Android Studio/Gradle", but to be adapted to vb.net.
Or you can have "fake revision number".
For a more complete build Assembly file generation, see that maven plugin "maven-git-commit-id-plugin" (again, to be adapted to a vb.net build).
It can generate a file as complete as:
{
"branch" : "testing-maven-git-plugin",
"describe" : "v2.1.0-2-g2346463",
"commitTime" : "06.01.1970 # 16:16:26 CET",
"commitId" : "787e39f61f99110e74deed68ab9093088d64b969",
"commitIdAbbrev" : "787e39f",
"commitUserName" : "Konrad Malawski",
"commitUserEmail" : "konrad.malawski#java.pl",
"commitMessageFull" : "releasing my fun plugin :-)
+ fixed some typos
+ cleaned up directory structure
+ added license etc",
"commitMessageShort" : "releasing my fun plugin :-)",
"buildTime" : "06.01.1970 # 16:17:53 CET",
"buildUserName" : "Konrad Malawski",
"buildUserEmail" : "konrad.malawski#java.pl"
}
That illustrates how you can ask the git repo for all kind of different information (not just the date, but the branch, committer, commit message, ...).
See the DescribeCommand.java for more details on the implementation.
I'm still trying to figure out how the revision numbering works with bzr, despite having read the understanding revision numbers bzr documentation.
I have a local branch of an upstream repository. The local revision is 689, and I haven't made any local changes.
If I do bzr missing url/to/upstream, bzr tells me that I'm missing 10 revisions: 689-698.
Clearly the upstream revision numbering changed, since the remote 689 is now different from my local 689. What I'm trying to figure out is:
What sequence of events causes an upstream branch to get renumbered? Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream? Is there a way to retrieve this using command-line bzr and/or loggerhead?
You have 2 questions there, so:
Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
Yes, that's exactly what happened.
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream?
For CLI bzr:
Simple method: run bzr log -n0 --show-ids and search the output for your revision-id. Then scroll back to the top and see which revision has your revision id merged.
You can use qlog command (from QBzr plugin) to make your history exploring much pleasant.
With bzr 2.3+ you can use mainline: revision modifier: bzr log -r mainline:your-revid
In CVS, my working copy (WC) is on a certain branch (which we'll call "foo"). There have been other changes checked into foo by another dev. I want to do a diff between my WC and the upstream state of foo. Normally, when working in the trunk (HEAD), I just do a cvs diff, and that's fine. But for some reason when doing a plain cvs diff in the branch, the diff is empty. When I try to use "cvs diff -r foo", the diff shows up, but it is inverted -- upstream additions are shown with minuses, and upstream removals are shown with pluses.
How can I either: (1) get CVS to diff "the other way" (plus for upstream additions), or (2) invert a patch (in general)?
maybe what you want can be done by using interdiff from the patchutils package.
I often use it this way to see what has changed on the TRUNK for a given file:
cvs diff -up -r1 givenfile | interdiff /dev/stdin /dev/null
If the principal purpose of this is to check "what's up" in the central repo, I suggest you get yourselves a functional CVS viewer/browser/web thingy where you can browse and see the latest changes before updating. But assuming all you have is command-line CVS, I will attempt to give you a solution anyway :)
So, what you have here is a branch foo that went from A -> B, where B is the state of the branch (on the server) after the other developer's checkin, and A is the state you last updated your working copy to.
When just doing a plain cvs diff in this situation, you'll see your local changes compared to A since A is what you have checked out. The local CVS state will show that each file comes from the A revision on the foo branch, and when diffing your CVS client will download that revision from the server. In your case I'm guessing you have no local changes since your cvs diff is empty.
Then, when you do a cvs diff -r foo you're diffing your local A (or A+changes) against the server's foo (which currently is at B) - and the changes required to get from the server's B to your A+changes is exactly the opposite of the other developer's check-in, plus your own local changes.
Now, if you really really want to know how B (or tip-of-foo) compares to A (the pristine version of whatever you currently have checked out), what I think you have to do is set a tag on your working copy, then diff that tag against the state of the branch. Something like this:
cvs tag pistos_temp1
cvs diff -r pistos_temp1 -r foo
# And clean up by deleting the tag afterwards:
cvs tag -d pistos_temp1
You can try export a file from the branch to some temporary file and then make diff between your working copy and this temp file. It seems to be the easiest way.