modules/hgweb/files/hgaccess/repos/hgaccess - Issue 29323409: Issue 2867 - Introduce module hgweb and corresponding server role

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments.

Keyboard Shortcuts

	File
u :	up to issue
m :	publish + mail comments
M :	edit review message
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line
<Enter> :	respond to / edit current comment
d :	mark current comment as done

	Issue
u :	up to list of issues
m :	publish + mail comments
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue
# :	close issue

	Comment/message editing
<Ctrl> + s or <Ctrl> + Enter :	save comment
<Esc> :	cancel edit

Side by Side Diff: modules/hgweb/files/hgaccess/repos/hgaccess

Issue 29323409: Issue 2867 - Introduce module hgweb and corresponding server role (Closed)

Patch Set: Issue 2867 - Fixes for issues discovered during test + merge with upstream Created Aug. 17, 2015, 10:50 a.m.

Left:
Right:

Use n/p to move between diff chunks; N/P to move between comments.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 vagrant
	Felix Dahlke 2015/08/17 18:05:03 Shouldn't this move to modules/private? Shouldn't this move to modules/private? mathias 2015/08/17 18:16:45 There's no need for that, one can easily introduce Show quoted text On 2015/08/17 18:05:03, Felix Dahlke wrote: > Shouldn't this move to modules/private? There's no need for that, one can easily introduce a private version and link it using the $hgweb::hgaccess parameter. One can also use this one as-is, and immediately after the initial provision push new content to the repository with the Vagrant key - just as one would do in development -, but then also removing the Vagrant key in the same turn. By the way, I recommend having the Vagrant key registered with the own agent anyway. When working with Vagrant, especially when debugging multiple boxes that talk to each other, that is. Felix Dahlke 2015/08/17 18:21:20 Seems pretty inconsistent with how we usually do i Show quoted text On 2015/08/17 18:16:45, mathias wrote: > On 2015/08/17 18:05:03, Felix Dahlke wrote: > > Shouldn't this move to modules/private? > > There's no need for that, one can easily introduce a private version and link it > using the $hgweb::hgaccess parameter. One can also use this one as-is, and > immediately after the initial provision push new content to the repository with > the Vagrant key - just as one would do in development -, but then also removing > the Vagrant key in the same turn. Seems pretty inconsistent with how we usually do it to me: We require a resource from private, then supply something practical for development in private-stub. Why handle it different in this particular module?
OLD	NEW

« no previous file with comments | « hiera/roles/hgwebserver.yaml ('k') | modules/hgweb/files/hgaccess/users/vagrant » ('j') | modules/hgweb/manifests/init.pp » ('J')