On Tuesday 06 October 2009 01:00:39 Luke Kanies wrote: > 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.
Sorry for the late response, was away for a while. Does it really matter in that case though? If the point is to store changed files in a VCS so that you get access to history of changes, etc. it seems that humans would be direct users of that feature. And humans probably wouldn't like using content-based addressing directly and so git's CAF seems like an implementation detail. I don't know enough about implementation of git so correct me if I'm wrong, but content-based addressing is mainly useful for storage optimization anyways, is it not? -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify [email protected] John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
