Difference between revisions of "Talk:VCS package guidelines"

From ArchWiki
Jump to: navigation, search
(question about adding guidline for firewall-friendly protocols)
(More on git pkgver()'s: new section)
(32 intermediate revisions by 11 users not shown)
Line 1: Line 1:
Q: Any reason for using 'svn co' instead of 'svn export'? export is way faster for these situations and it doesn't create all the .svn files.
+
== https:// vs git:// ==
  
A: Look at http://bbs.archlinux.org/viewtopic.php?pid=245213
+
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)
  
What's the reason for using 'cp -r $_svnmod $_svnmod-build' instead of using 'svn export $_svnmod $_svnmod-build'?--[[User:BertiBoeller|BertiBoeller]] 19:21, 15 March 2009 (EDT)
+
== 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)
  
-- no reason afaik. Please send a patch against /usr/share/pacman/PKGBUILD-svn.proto from abs package to the bug tracker. --[[User:Shining|shining]] 07:59, 4 October 2009 (EDT)
+
: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 ==
  
Please submit the Mercurial proto to flyspray so that it can be added to abs package.
+
The #fragment part of the VCS source URL has a different meaning for each type of VCS.
--[[User:Shining|shining]] 17:37, 18 December 2009 (EST)
+
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)
Q: 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)?
+
 
 +
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&#61;("$pkgname::git://path.git#branch&#61;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

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)