Difference between revisions of "Talk:VCS package guidelines"
(→Sed -> tr: new section) |
|||
(14 intermediate revisions by 9 users not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
== https:// vs git:// == | == https:// vs git:// == | ||
Line 7: | Line 4: | ||
--[[User:Mitch feaster|Mitch feaster]] 14:34, 15 November 2011 (EST) | --[[User:Mitch feaster|Mitch feaster]] 14:34, 15 November 2011 (EST) | ||
− | == | + | == Updating a CVS repo == |
+ | I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)? <br> | ||
+ | -- [[User:Dracorp|Dracorp]] ([[User talk:Dracorp|talk]]) 09:31, 6 April 2013 (UTC) | ||
− | + | :CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added. | |
+ | :-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 22:44, 15 April 2013 (UTC) | ||
− | == | + | == checking out branches/tags needs clarification == |
− | + | The #fragment part of the VCS source URL has a different meaning for each type of VCS. | |
− | + | This can be confusing for people, especially when they are trying to checkout a specific branch or tag. | |
+ | Examples would reduce the chance for confusion a lot. | ||
− | + | fictional examples for git and svn (don't have experience with bzr or HG) | |
− | |||
− | |||
− | |||
− | :: | + | check out branch git_test of git://myproject.com into folder my_git_code : |
+ | my_git_code::git://myproject.com/#branch=git_test | ||
− | + | Check out branch svn_test of svn://myproject.com into folder my_svn_code : | |
+ | my_svn_code::svn://myproject.com/branches/svn_test | ||
− | [[ | + | [[User:Lone Wolf|Lone_Wolf]] ([[User talk:Lone Wolf|talk]]) 20:49, 16 April 2013 (UTC) |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | == pkgver() for git == | |
− | + | I'd like to suggest using HEAD instead of master in example pkgver(), i.e. | |
− | + | {{bc| | |
− | {{ | + | pkgver() { |
+ | cd local_repo | ||
+ | echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) | ||
+ | } | ||
+ | }} | ||
+ | instead of | ||
+ | {{bc| | ||
+ | pkgver() { | ||
cd local_repo | cd local_repo | ||
echo $(git rev-list --count master).$(git rev-parse --short master) | echo $(git rev-list --count master).$(git rev-parse --short master) | ||
} | } | ||
+ | }} | ||
+ | |||
+ | Pros: | ||
+ | If source line contains fragment, e.g. {{ic|source=("$pkgname::git://path.git#branch=name")}}, offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug. | ||
+ | |||
+ | Cons: | ||
+ | Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers. | ||
+ | |||
+ | == More on git pkgver()'s == | ||
+ | |||
+ | I would also like to see packages use pkgver fucntions like this: | ||
+ | |||
+ | git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g' | ||
− | + | so they are more friendly to vercmp. | |
− | + | Current behaviour using git-git as an example: | |
− | {{ic| | + | current ver: {{ic|1.8.2.210.g123abc-1}} |
+ | next ver: {{ic|1.8.2.1.50.g123abc-1}} | ||
+ | vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc | ||
+ | 1 # the first is greater than the second | ||
− | + | Right now, the current version is actually greater than the new version, causing a downgrade. If {{ic|r}} is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly. | |
− | + | current ver: {{ic|1.8.2.r210.g123abc-1}} | |
+ | next ver: {{ic|1.8.2.1.r50.g123abc-1}} | ||
+ | vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc | ||
+ | -1 # the first is less than the second | ||
− | + | [[User:KaiSforza|KaiSforza]] ([[User talk:KaiSforza|talk]]) 20:42, 18 April 2013 (UTC) | |
− | + | == Sed -> tr == | |
− | + | {{ic|<nowiki>sed 's|-|.|g'</nowiki>}}'s could be replaced with just {{ic|tr - .}}'s as well. --[[User:Det|Det]] ([[User talk:Det|talk]]) 13:10, 2 May 2013 (UTC) |
Revision as of 13:10, 2 May 2013
Contents
https:// vs git://
Could we consider a guideline to use firewall-friendly protocols when possible (e.g. https://github.com/matplotlib/matplotlib.git instead of git://github.com/matplotlib/matplotlib.git)? --Mitch feaster 14:34, 15 November 2011 (EST)
Updating a CVS repo
I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)?
-- Dracorp (talk) 09:31, 6 April 2013 (UTC)
- CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.
- -- Jstjohn (talk) 22:44, 15 April 2013 (UTC)
checking out branches/tags needs clarification
The #fragment part of the VCS source URL has a different meaning for each type of VCS. This can be confusing for people, especially when they are trying to checkout a specific branch or tag. Examples would reduce the chance for confusion a lot.
fictional examples for git and svn (don't have experience with bzr or HG)
check out branch git_test of git://myproject.com into folder my_git_code :
my_git_code::git://myproject.com/#branch=git_test
Check out branch svn_test of svn://myproject.com into folder my_svn_code :
my_svn_code::svn://myproject.com/branches/svn_test
Lone_Wolf (talk) 20:49, 16 April 2013 (UTC)
pkgver() for git
I'd like to suggest using HEAD instead of master in example pkgver(), i.e.
pkgver() { cd local_repo echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) }
instead of
pkgver() { cd local_repo echo $(git rev-list --count master).$(git rev-parse --short master) }
Pros:
If source line contains fragment, e.g. source=("$pkgname::git://path.git#branch=name")
, offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug.
Cons: Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers.
More on git pkgver()'s
I would also like to see packages use pkgver fucntions like this:
git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
so they are more friendly to vercmp. Current behaviour using git-git as an example:
current ver: 1.8.2.210.g123abc-1
next ver: 1.8.2.1.50.g123abc-1
vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc 1 # the first is greater than the second
Right now, the current version is actually greater than the new version, causing a downgrade. If r
is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.
current ver: 1.8.2.r210.g123abc-1
next ver: 1.8.2.1.r50.g123abc-1
vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc -1 # the first is less than the second
KaiSforza (talk) 20:42, 18 April 2013 (UTC)
Sed -> tr
sed 's|-|.|g'
's could be replaced with just tr - .
's as well. --Det (talk) 13:10, 2 May 2013 (UTC)