1

I am looking for a way to implement a configuration management solution for software like JIRA or Confluence which do come as archives but where you do have to modify few configuration files or to add missing jars files.

Each time a new version comes, you have to reapply your changes.

Obviously I was thinking about using patch queues but it doesn't work well in this case because the archives are usually over 200 MB and most binary files are changes, so if you put them in a SCM its size will easily grow too fast. Also there is no real need on keeping these files in the repo, what counts are only the changes, file additions (can be binary) or text file changes.

What would be the proper way to implement this, in such way that I can automate the upgrade / patching when I have a new version. Obviously if applying the patch fails I could stop the automated process, but based on the kind of changes made to the config files, the change of this to happen is almost zero.

Note: If possible I would be inclined to use git to keep track of these changes.

sorin
  • 161,544
  • 178
  • 535
  • 806
  • 1
    Why using Git? You could simply create a `diff` based on the modification and use `patch` to apply them. – rlegendi Oct 08 '14 at 11:27
  • sometimes there are added files, binary files like jar ones and I guess patch is not of much use for these. Also having a huge patch file doesn't help too much. – sorin Oct 08 '14 at 12:32

1 Answers1

1

The best way to handle this, if upstream does not use git, is to manually replicate that functionality using something called a vendor branch (the actual name of the branch doesn't matter, I will call it "upstream" here, but when doing searches, I believe vendor branch is the term of the art).

This is best done BEFORE making any local modifications, so that git will be able to track what is going on. If you can rewrite history (force push, making everyone else essentially reclone or rebase) then you can kinda do it after (there are some even more tricky ways of doing it, which I don't recommend).

The way to do this is:

  • Create the new directory and unpack your vendor's source code into it
  • git init to create the git repository
  • git add -Af . (assuming that this is a true fresh unpack without any unwanted files in it)
  • git commit -m "Some text describing where you got the source code, how the vendor identified it, etc"
  • git branch -m master upstream will name the fresh new commit to master
  • At this stage, you modify the master branch to do what you want

At some later point, vendor makes a new release. You then.

  • git status and git stash -a and friends to make sure everything (tracked, untracked, whatever) is committed , stashed, or can be deleted.
  • git checkout upstream
  • find . -maxdepth 1 -mindepth 1 ! -name .git -print0 | xargs -0 rm -f Clean the directory of everything.
  • Unpack the vendor code
  • git add -Af .; git commit -m "similar description as above" will commit the vendor information
  • git checkout master; git merge upstream will merge in the changes vendor made. You go through normal conflict resolution.
  • Continue with your changes to the vendor package.

If you ever want to send a fix back to the vendor, make a new branch off of vendor to the patch, then merge that patch back into master. You can send the vendor that patch and if they pick it up all will be well and everything should work automatically. If they modify it, you will have to go through conflict resolution as normal. However, the key here is that the vendor branch itself should always remain pristine.

If you want to ignore binaries and only deal with configuration files, you can add the binaries to .gitignore before doing the vendor branch commits (and don't use -f to git add -A).

Seth Robertson
  • 30,608
  • 7
  • 64
  • 57