scm_track_enabled docs?

[Dick Davies]

Does anyone have any documentation on what

scm_track_enabled: 1

should do? I'm assuming cobbler creates its own git repo and starts versioning
its config, but I've no idea where it would/should be. Thanks!

[Michael DeHaan]

Dick Davies wrote:
>  Does anyone have any documentation on what
>
>  scm_track_enabled: 1
>
>  should do? I'm assuming cobbler creates its own git repo and starts versioning
>  its config, but I've no idea where it would/should be. Thanks!
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
Thanks for the heads up, we don't have a Wiki page on this -- it works 
pretty much as it says but I
should be more explicit and it should be on the Wiki too.

The settings file says:

# enables a trigger which version controls all changes to /var/lib/cobbler
# when add, edit, or sync events are performed. This can be used
# to revert to previous database versions, generate RSS feeds, or for
# other auditing or backup purposes. git is the recommend SCM
# for use with this feature.
 
The git repo is just /var/lib/cobbler/.git, so it makes /var/lib/cobbler 
a git repo.

You can cd into that directory (/var/lib/cobbler) and run "git log" (or 
any other git commands) to verify that, after you performed
an edit command after turning on the trigger.

Here's the source (as of now), which shows which directories under 
/var/lib/cobbler are tracked

http://github.com/mpdehaan/cobbler/blob/0f85c4ebb7d896868b1f1e2fbe98f1ff8...

Any ideas you have on how we can make this better are welcome.  One 
known is that if you do a lot of batch API edits, edits with xargs and 
so forth, (or cobbler replicates) it generates an event once for each 
edit, which can be a lot and the trigger (because it must fire up git 
each time) can be a little slow.   We've theorized some way to open up a 
transaction may be a good idea, and then teaching the trigger to make 
less checkins.    Solution there TBD as we've been generally looking at 
other things. 

--Michael

[Dick Davies]

On Mon, Jun 1, 2009 at 2:16 AM, Michael DeHaan <mdehaan(a)redhat.com&gt; wrote:
>  Dick Davies wrote:
> > Does anyone have any documentation on what
> >
> > scm_track_enabled: 1
> >
> > should do? I'm assuming cobbler creates its own git repo and starts versioning
> > its config, but I've no idea where it would/should be. Thanks!
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
>
>  Thanks for the heads up, we don't have a Wiki page on this -- it works
>  pretty much as it says but I
>  should be more explicit and it should be on the Wiki too.
>
>  The settings file says:
>
>  # enables a trigger which version controls all changes to /var/lib/cobbler
>  # when add, edit, or sync events are performed. This can be used
>  # to revert to previous database versions, generate RSS feeds, or for
>  # other auditing or backup purposes. git is the recommend SCM
>  # for use with this feature.
>
>  The git repo is just /var/lib/cobbler/.git, so it makes /var/lib/cobbler
>  a git repo. 
Oh yeah, there it is :) Thanks!
>  Here's the source (as of now), which shows which directories
> under
>  /var/lib/cobbler are tracked 
Cool, didn't realise there was a github mirror of the Cobbler repo.
> http://github.com/mpdehaan/cobbler/blob/0f85c4ebb7d896868b1f1e2fbe98f1ff8...
>  Any ideas you have on how we can make this better are welcome.  One
>  known is that if you do a lot of batch API edits, edits with xargs and
>  so forth, (or cobbler replicates) it generates an event once for each
>  edit, which can be a lot and the trigger (because it must fire up git
>  each time) can be a little slow.   We've theorized some way to open up a
>  transaction may be a good idea, and then teaching the trigger to make
>  less checkins.    Solution there TBD as we've been generally looking at
>  other things. 
When I get a bit of time, I'll have a look. Thanks again.