Difference between revisions of "Talk:VCS package guidelines"

From ArchWiki
Jump to: navigation, search
(Sed -> tr: new section)
(44 intermediate revisions by 18 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)
  
 +
== 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 ==
  
Just wondering if the versionpkg part will be removed - I hear that makepkg now has versionpkgs functionality...
+
The #fragment part of the VCS source URL has a different meaning for each type of VCS.
--[[User:Ak5|ak5]] 16:55, 8 June 2008 (EDT)
+
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.
  
-- done (wide-eye)
+
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
  
The title for this article indicate guidelines for CVS and SVN, but git and darcs are also included. Perhaps the title should be changed to reflect this, or git and darcs guidelines should be separated off into their own articles. --[[User:Mentallaxative|mentallaxative]] 01:48, 18 October 2008 (EDT)
+
[[User:Lone Wolf|Lone_Wolf]] ([[User talk:Lone Wolf|talk]]) 20:49, 16 April 2013 (UTC)
  
----
+
== pkgver() for git ==
  
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)
+
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)
 +
 
 +
== 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

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)