On Oct 5, 2009, at 8:56 AM, Michael Gliwinski wrote:
>
> On Monday 28 September 2009 09:16:37 sam wrote:
>> On Sep 28, 3:02 pm, Luke Kanies <[email protected]> wrote:
>>> On Sep 27, 2009, at 5:41 PM, sam wrote:
>>>> Hello,
>>>> I am thinking of wiring filebucket to save to a git repo.
>>>> It would allow diffs and history, is that something worthwhile for
>>>> inclusion ?
>>>
>>> I think it's a great idea. In fact, I've written a prototype of it:
>>>
>>> http://gist.github.com/77811
>>>
>>> It's just a thin executable, without the Puppet integration, and
>>> it's
>>> all execs rather than library calls. It also doesn't do any of the
>>> history, which you'd obviously want -- it's just the blobs, with no
>>> branches or anything.
>>>
>>> I'd love to have this supported. How were you thinking of doing it?
>>
>> the filebucket would store the replaced files in a git repo on the
>> local host, using rubygem-git and commit at the end of a puppet
>> run, a
>> file would be placed into $GITROOT/$FULLPATH of original file. no
>> symlinks.
>> filebucket { main: path => git://$gitpath }
>>
>> A centralized git server I suppose is nice, keep a branch per server
>> (all lost on server renames). Would the best way be keep a git
>> clone -
>> l per server, then pull, add the file, then push back to the branch ?
>> sounds like a bottle neck. if there is interest I would prefer to
>> keep
>> it as a stage 2.
>>
>> The history/diffs would be something a person would run on the git
>> repo themselves, I don't have good ideas of integrating that part
>> into
>> puppet or it's usability. it's so much easier to use git to find the
>> rev you want and you would need to add the file back to puppetmaster
>> manually as the restored file would have been a puppet template or a
>> file resource (tidy aside)
>>
>> did you expect more or have a more thought out idea?
> This is a very good idea in general. I would however urge you to
> consider
> having a thin "glue" layer between the client code and the actual
> VCS (in
> this case git). In other words what I mean is, regardless if you call
> commands or use a library to talk to git, do it through an
> abstraction layer.
> This way it would be possible for ppl to use different VC systems.
>
> In my company we use bazaar for example and I know some ppl on the
> list use
> subversion, it would be better to allow them to use their VCS of
> choice.
I've thought about this a bit, and if it's possible I'd like to do so,
but I'm not sure it is actually possible.
The problem is that git actually works really well as a content-
addressable file system -- you can provide content and get a checksum
back, and provide a checksum and get content back. While other VCSes
do well at the basic interactions, git's design as a CAF first and VCS
second gives it additional functionality here.
I'd like to be proven wrong, though.
--
One of the Ten Commandments for Technicians:
(7) Work thou not on energized equipment, for if thou dost, thy
fellow workers will surely buy beers for thy widow and
console her in other ways.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
