On 01/18/2013 10:55 AM, Hugo Mills wrote:
On Fri, Jan 18, 2013 at 10:49:20AM -0500, Gene Czarcinski wrote:
On 01/18/2013 09:44 AM, David Sterba wrote:
On Fri, Jan 18, 2013 at 09:16:00AM -0500, Gene Czarcinski wrote:
Sergei Trofimovich (1):
version.sh: fix version when built from tarball
While you are about it, how about adding in this fix from Dieter Ries to fix
version a little more:
http://article.gmane.org/gmane.comp.file-systems.btrfs/20069
I did not notice it before, but Dieter's patch does not work when progs
are built from .git repository
-echo "#define BTRFS_BUILD_VERSION \"Btrfs $v\"" >> .build-version.h
+echo "#define BTRFS_BUILD_VERSION \"$v\"" >> .build-version.h
$v is set with the git tag, so the "Btrfs" string does not appear in the
output (eg. mkfs.btrfs).
Technically, $v should always contain some sort of a tag, Sergei's patch
hardcodes it to the latest one for the non-git case. This is IMHO the
right approach.
OK, I see what you mean. However, the current situation when btrfs
is built from a tarball results in:
btrfs --version
Btrfs Btrfs v0.19
I guess one problem here is that there's no canonical way of
generating a tarball (without the git files) from a git checkout, with
detailed version information. So what's happening, I suspect, is that
the distributions/people producing source tarballs of btrfs-progs are
checking out the git tree, deleting .git, and tarring up that, which
loses any git versioning.
I think a solution may be to have a "dist" or "tar" make target
which does the above automatically and includes a suitably-generated
version.h in the tarball.
Hugo.
If you use gitweb to addess btrfs-progs.git, there is a very nice label
"snapshot" beside each commit entry and clicking it will get you a
tarball of the tree from that point.
I am a newbie at the git stuff but it seems to me that a few more
branches are needed with stable branches marked as such and one or more
unstable development branches ... at least that is what I have seen done
on other projects such as NetworkManager and libvirt. The branch will
then include a hardcoded value for the version id which will/can be
different in each branch. And they also usually have a "make dist"
which packages things up into a tarball.
The snapshot-tarball from gitweb includes the first part of the git
commit id. It is just that it is not included in a file. The tarball
does not includes only ".gitignore". Rpms (and I assume the debian
packages also) are based on tarball source with additional patches as
necessary. I have seen only one fedora package actually use git in the
rpm and that was grub2.
While running stuff directly from a local git repository may be nice for
developer, actual inclusion in a distribution package will (I believe)
be via tarball.
and
mkfs.btrfs -V
mkfs.btrfs, part of Btrfs Btrfs v0.19
There must be a way to reliably just have one "Btrfs" and I will
look into it.
As I was sitting here typing this message, the "solution" occurred to me:
Do not use Dieter's patch because it is unnecessary ... Sergei's patch
does things correctly already.
Sorry for the noise on the list. However, I do suggest that more git
branches be used rather than having everything under "master".
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
