Difference between revisions of "Talk:VCS package guidelines"
m (doh) |
(→More on git pkgver()'s: new section) |
||
(45 intermediate revisions by 19 users not shown) | |||
Line 1: | Line 1: | ||
− | + | == 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)? | |
+ | --[[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 | ||
+ | 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: | ||
+ | |||
+ | 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) |
Revision as of 20:42, 18 April 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