Bug #8331

vcsrepo: svn provider flags local repository as absent even when it was created with puppet

Added by Theo Cabrerizo Diem almost 2 years ago. Updated over 1 year ago.

Status:Needs DecisionStart date:07/08/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:vcsrepoSpent time:-
Target version:-
Keywords: Branch:

Description

I’m trying to setup a svn central repository.

$ puppet resource vcsrepo /tmp/test ensure=present provider=svn
warning: Found multiple default providers for vcsrepo: svn, git; using svn
notice: /Vcsrepo[/tmp/test]/ensure: created
vcsrepo { '/tmp/test':
  ensure => 'absent',
}

Repository is create, I can check out, work, commit , but then if I run puppet again:

puppet resource vcsrepo /tmp/test ensure=present provider=svn
err: /Vcsrepo[/tmp/test]/ensure: change from absent to present failed: Execution of '/usr/bin/svnadmin create /tmp/test' returned 1: svnadmin: '/tmp/test' is a subdirectory of an existing repository rooted at '/tmp/test'
vcsrepo { '/tmp/test':
  ensure => 'absent',
}

Shouldn’t it report as ‘present’ even when it did create it ?

History

#1 Updated by Theo Cabrerizo Diem almost 2 years ago

(don’t know why the formatting went away when submitting)

I’m trying to setup a svn central repository.

# puppet resource vcsrepo /tmp/test ensure=present provider=svn

warning: Found multiple default providers for vcsrepo: svn, git; using svn
notice: /Vcsrepo[/tmp/test]/ensure: created vcsrepo { '/tmp/test': ensure => 'absent', }

Repository is created, I can check out, work, commit , but then if I run the same puppet line again:

# puppet resource vcsrepo /tmp/test ensure=present provider=svn
err: /Vcsrepo[/tmp/test]/ensure: change from absent to present failed: Execution of ‘/usr/bin/svnadmin create /tmp/test’ returned 1: svnadmin: ‘/tmp/test’ is a subdirectory of an existing repository rooted at ‘/tmp/test’
vcsrepo { ‘/tmp/test’: ensure => ‘absent’, }`

Shouldn’t it report as ‘present’, line when it did create it ?

#2 Updated by Ken Barber almost 2 years ago

  • Category set to vcsrepo

#3 Updated by James Turnbull almost 2 years ago

  • Status changed from Unreviewed to Accepted

#4 Updated by Nan Liu over 1 year ago

  • Description updated (diff)

Well, SVN isn’t a distributed version control software, so the central repo isn’t really a SVN repository. If you run svn list on /tmp/test it will complain:

svn: '.' is not a working copy

So in this case it’s better to model the svn repository as:

exec { "create_repo":
    command => "svnadmin create /tmp/test",
    creates => "/tmp/test",
}

I think for the intended use case, it makes sense to have a source for svn (even though it’s technically a parameter). Should this be considered a bug or a limitation of svn?

#5 Updated by Nan Liu over 1 year ago

  • Status changed from Accepted to Needs Decision

#6 Updated by Theo Cabrerizo Diem over 1 year ago

Since it should be dealing with the “central” repo and not a checked out copy you cannot use “svn” commands.

IMHO we already rely on svnadmin, so why not using svnlook ? svnlook is usually provided in the same package as svnadmin (which often is just “subversion”) since you need to use it for pre/post commit hooks.

$ stat /tmp/myrepo
stat: cannot stat `/tmp/myrepo': No such file or directory
$ svnlook uuid /tmp/myrepo
svnlook: E000002: Can't open file '/tmp/myrepo/format': No such file or directory
$ echo $?
1
$ svnadmin create /tmp/myrepo
$ svnlook uuid /tmp/myrepo
eedd6f53-0906-46ad-976a-5a29d8726cc7
$ echo $?
0

Printing the uuid shouldn’t trigger anything dangerous or cpu intensive in order to at least tell if the directory is a valid svn “central” repo or not.

EDIT: just for clarity, I’ve meant to use both existing method on working_copy_exists? (File.directory?(File.join(@resource.value(:path), ‘.svn’)) and the suggested one to catch both situations (a checked out svn dir or a “central” repo created.)

Also available in: Atom PDF