On Mon, Oct 6, 2008 at 4:17 PM, dd-b <[EMAIL PROTECTED]> wrote: > On Oct 3, 5:00 pm, "Brian Mathis" <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 3, 2008 at 5:24 PM, dd-b <[EMAIL PROTECTED]> wrote: > >> > For me, source control doesn't address the same problem. I'm using >> > source control on my puppet files collection, but I periodically need >> > access to old versions intermediate between when I have now and what I >> > last committed. Except for Sun's old (and otherwise disastrous) NSE >> > and a small-company product called DRTS that I don't think exists any >> > more either, I haven't run into a version-control system that handles >> > that case decently. >> >> It sounds like you need to be committing more often. There should >> never be a time when you have a config that you find useful (ie: >> something that you are satisfied is working) that is not committed. >> If you find that you need revisions that are "in between" two commits, >> then you didn't commit often enough. > > Sometimes I need access to versions more recent than the last commit > during periods when the code wasn't even compiling cleanly (never mind > "working") -- clearly such code should *not* be checked in to the > public repository! (The thing with NSE and DRTS was that you had a > private repository as well as one or more layers of public ones, so I > could check into my private one as often as you (and I) think is > useful without exposing my intermediate states to the world. I've > since my previous post seen that GIT, which is actually current and > even relevant to Puppet, may also support that working style.) > > Also, I have to make a conscious decision to commit, and it's easier > to just version the saves than to do manual commits and make up > comments and so forth that frequently. >
Still, it sounds like you need to modify your workflow instead of blaming the revision software. There's a reason the market has chosen these kinds of revision systems. I think what you need to be doing is: - When you start making changes, make a branch in your RCS - As you make changes, commit each step in that branch. Each commit should only contain discrete parts, like "fixed typo in node name", or "updated apache config to support ssl". Commits should not contain a big chunk of unrelated changes. - Once you have tested and are ready to "release", you merge that branch back into the "main" branch of the repository. It requires discipline and probably some changes to the way you are used to working. Also, it's common to have files laying around with different versions of intermediate files, etc..., but those should be in your test area and ultimately do not get checked in to the system. Anything that's left over that you don't want to check-in should be considered "notes" and maybe filed away in a notebook/txt file and not in the repository or as files junking up the Puppet directories. Look at it this way: the rest of the open source (and many closed source) world uses these types of RCS systems just fine, so either: a) you are much smarter than everyone else and could become a millionaire with your approach - OR - b) you might learn a thing or two by looking at how most other people do it --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
