[rancid] Rancid and Git

[heasley]

Wed, May 21, 2014 at 08:07:26PM +0000, Brown, David M JR:
> 
> >----
> >> 	$BASEDIR is the dir into which all groups go. If you put a generic
> >> lockfile here you will make it so multiple groups can't be polled at one
> >> time. Typically a temp dir is used where the file includes the group
> >>name
> >> so there is no stepping on of toes, and stale lockfiles aren't left in
> >> unexpected places.
> >
> >The locks shouldn't slow down polling, the lock is only held when making
> >commits to the Git repository which shouldn't happen during polling
> >(unless I'm misunderstanding something about the code).  I needed the
> >locks because I need to run a series of git commands atomically or
> >changes from other groups might become part of the wrong commit.
> >----
> >
> >That seems out of scope to me.  Perhaps i do not yet understand the
> >process
> >in git.  how would the commits in one group become part of another group's
> >commit?  the commit occurs in the group's directory.
> 
> One of the big differences between svn commit and git commit is the
> current working directory doesn¹t matter for git and it does for svn. My
> guess is that they did this then to ensure that commits to on group don¹t
> have race conditions with another group being modified.
> 
> A fix to this would be to do a 'git commit -m ³$message² *' this should
> only commit things in the current working directory and not differences in
> the entire tree.
> 
> Hopefully this helps.
> 
> Thanks,
> - David Brown

I've been playing with git a bit to determine how to arrange the repository
and understand the commands.  I find the automatic search for changed files
unwelcome.

The original git patch arranges the repository at $BASEDIR (eg: /var/rancid),
which creates a single repository with all groups.

I experimented with creating a "remote" repository in $BASEDIR, then pushing
individual groups to it, but they clash, which I suspect has to do with
either the repository name (git push -u origin master).

Assuming that is not the problem with that arrangement, another possibility
is just making each group its own self-contained repository.  However, I
dislike this as well, as its easier to help users recover from RCS problems
when they can just rm-rf the group and check-out a fresh copy.

Also, I'd like to maintain the existing arrangement with CVS and SVN, where
each rancid group is it's own path that admins can remove their working copy
without remove-ing from the repository (yes, I understand that the history
remains).

Any guidance or comment welcome.