Talk:VCS package guidelines

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)