Version Control

Hey All,

Does anyone use Tower, et. al., for version control with their RW projects?

I do with Xcode and other development systems but have never given it a go with RW.

Any experience/advice anyone wants to share?

Thanks.
Blessings,
—Mark

1 Like

This has been in my radar too.

I do remember, on one of the podcast, Dan and Ben were talking about using GitHub with RW project files.

I’m using Git to handle my RW project files. But the file format is very inconvenient for version control as you can see any differences. It’s all some XML scrambled encoded binary stuff…

So, you can only use commit & restore and branch, but no merge nor diff.

Without version control how to merge versions if you have more than one developer working on in one site?

On macOS some files are just files, but some files are folders full of files – but just look like a single file in the Finder. This is called a “bundle file”. Some common examples are:

  • RTFD (.rtfd) – when you drop a picture into a TextEdit document that’s what it saves as by default
  • Apps (.app) – all macOS applications are bundle files

git isn’t especially good at dealing with files like this. for example: doing a merge of different branches would almost guarantee a corrupted project file.

so long as you treat the entire project as a single monolithic entity and keep to a single branch then there isn’t really any harm either. you would just need to be kind of careful.

i do store a bunch of tiny RW projects in my Stacks repo that i use for automatic testing. but it’s hardly a good example as the test files rarely change, are not used in a collaborative environment (i’m a solo developer) and tend to be relatively simple and small projects.

i do keep a time machine backup server on the network and have had pretty great results at rescuing lost/corrupted files with my time machine server.
not exactly the same thing or the same use case – but there’s obviously some overlap.

isaiah

1 Like

Should RapidWeaver (@dan) consider better git compatibility in a next version? It would be significative for team developers beyond sold developers.

@mario_br - it’s an interesting idea. but i honestly don’t really know how that would be tackled.

even though I’m not responsible for the RW file format – i do decide how stacks pages, partials, and a few other things get written to disk.

if you’re the technical sort and have some good ideas – i’m all ears. and if you’re not – just some pointers at other apps that work this way would help – i’d be happy to do the technical investigation leg work. :nerd_face::yum:

Don’t use binary data inside the plist.

Yeah, I know that’s easy to say for me if I don’t know the implications… :wink:

@instacks - that would definitely be a good start. and it would solve one problem… it would make the git repo much lighter because git could do diffs and store incremental data. and that would make uploads to GitHub much faster. i think JSON plists would be the way to go. :+1:

but it would also come at a cost. and not a small one. a serious potential for data loss.

if ever git did a merge of that data file then the file would surely become corrupt – and it probably doesn’t much matter if the file is an xml plist, json plist, or just a plain vanilla json file – the problem is that the file is not code. these files contain serialized objects. and serialized objects, no matter what format you write them in, don’t really handle merging very well.

this is roughly the same trouble that Xcode gets in when you try to merge branches with XIB file changes. even though xib’s are designed to have redundant structures to handle git merges, often you end up mangling them beyond hope. you can sometimes make manual repairs by blindly editing thousand-line long incomprehensible xml files, but usually the result is to back out of changes – and that sometime means losing a git rebase – and losing work.

i worry that if Apple’s Xcode team can’t solve this problem, then the problem may be very difficult indeed.

but i’m keeping an open mind. i feel like perhaps some sort of paradigm shift that looks at the problem really differently might make it feasible.

1 Like