Kactus: Design version control without changing tools | Hacker News Reader

Kactus: Design version control without changing tools

kactus.io

58 pointsdoener24 comments

"Design Version control without changing tools" ... that is, if you're on Mac OS and your tool is sketch.

Yes maybe it's pooly phrased. I was trying to convey that, as opposed to pretty much all the other version control tools for designers, Kactus doesn't force you into a workflow. It's more an additional step that comes after, just like when you code, git is a tool that you use after.

I’ve seen multiple version control apps pass by in recent years. However they seem to focus too heavy on one particular tool. For me as a designer I’m really looking for a version control system / app which handles multiple files from multiple software applications. On a regular day I use, Photoshop, Illustrator, Indesign, After Effects, Premiere Pro, and some other smaller tools as a base. If there ever could be a (local— because of the large file sizes in video) versioning system which brings them all together that would mean the world. Preferably in a nice gui application. And I know these apps have failed in the past but I think there might just be a market for it. (Instead of versioning it all in the finder / explorer myself)

Zeplin is the current darling. It's real power is in digesting designs into code to make handoff to developers easier.

AFAIK, many of those programs use non-free formats which makes it challenging to implement what you're talking about. Vendor lock-in sucks.

I seem to remember that a reason why Git wasn’t popular with game dev (and why it wouldn’t be with designers, besides usability) is that it handled binary diffs terribly (ie it would store the whole updated file, even if just a few bits had changed). Am I remembering correctly? If so, is that now addressed?

Also it didn’t have native file locking which makes it a no-go for any non-text often changing content. I’m not sure if this has been addressed, or whether some plugin has become the de-facto standard to solve this?

File locking basically being the antithesis to a distributed version control system, I can't really see how it would fit into Git. How would it work for a system with no central repository?

It might make more sense to implement this within the services that emulate a central repository on top of Git.

You lock it in one central repository. There is typically a blessed repository somewhere, at least in every single project I have seen.

I know of no one and no project that uses the bare git in a truly distributed sense that isn’t just one central repo with multiple users, or in rare cases a hierarchy of repos such as the Linux kernel.

This is also why the github/lab style services are so popular - it’s what people need. But I don’t think that’s a reason to keep this feature away from git itself. I don’t think many want to have to use github just to get this one feature, and as I said, for any repo hosting binary content (common) and using one or more central blessed repos (nearly universal) - it’s very hard to live without.

Gitolite has a fine implementation of locking in Git.

http://gitolite.com/gitolite/locking/#locking-binary-files

Locking is implemented centrally by gitolite. It would be nice if other services implemented the same mini-protocol.

Sketch files are zip archives containing a bunch of JSON, so they're likely looking at/storing extracted state.

There are things like git lfs, but these feel like hackarounds rather than proper fixes to me. Github's tiny LFS quotas giving me frustration over ~100MB of lfs data don't help either, which I can't raise because I'm a random dude who lacks billing/admin permissions for PistonDevelopers: https://github.com/PistonDevelopers/VisualRust/issues/302

If git supported large files well you'd still have that problem; Github is just not interested in becoming an hosting provider for such files.

And while LFS is certainly a hack, being separate is actually an advantage here; PistonDevelopers could host their own LFS server while continuing to use Github for their development, whereas if it was integrated they would be forced to pay GH or move out.

That said, I prefer git-annex to LFS, since it doesn't need a custom server; you can just use a "dumb" file server (rsync, webdav, S3, etc), with all the metadata being synced over the git repo.

> Github is just not interested in becoming an hosting provider for such files.

That's a strange claim given that they authored git lfs in the first place and run servers for it.

> That said, I prefer git-annex to LFS, since it doesn't need a custom server; you can just use a "dumb" file server (rsync, webdav, S3, etc), with all the metadata being synced over the git repo.

Significantly better multi-remote support as well from what I can tell, which would make transitioning or partially transitioning significantly easier. OTOH, no filters so you'll be manually spamming `git annex get` as I understand it: http://git-annex.branchable.com/todo/smudge/

Nope - short answer - git internals store whole files even for the smallest change. The thinking is that "disk is cheap (compared to computing time)", and there are different algorithms to present diffs / history that's useful having the original files around.

At first glance, that seems like a bad idea, but peeking into the '.git' folder, there are certain advantages of it over diff/patch storage formats and vice versa.

Longer answers: https://stackoverflow.com/questions/41482898/git-seems-to-st...

I think Perforce does this too... it's not a problem as such, but since you can't silently rewrite history in Git it's somewhat hard to get rid of the old versions when they start taking up space. Perforce on the other hand lets you configure the history depth on a per-type or per-file basis. I think you can purge deleted files if you'd like, too? - you'd probably use this if you were keeping old builds in version control, or some other useful type of asset that's in principle possible to recreate.

This doesn't help in combination with its insistence on storing the entire repo locally - though it's possible Git LFS (which I haven't tried) would be able to help with this.

Lack of file locking is a genuine problem.

And I really don't think you can handwave away Git's terrible usability with a "besides"...

Pretty much every modern version control system treats binary files as undiffable and simply stores the whole thing as a hunk. The issue with Git affects pretty much all distributed version control since it requires keeping the entire history locally, so binaries with lots of changes vastly bloats the local repository. Stuff like Git LFS exists to work around that, by storing binaries in a central location instead, but that of course means that your system is no longer really distributed...

The website looks exactly the same as that from GitHub Desktop: https://desktop.github.com/

Saw this earlier today and the screenshots matched. Probably because they are using GitHub Desktop as a base?

github/desktop is MIT, so I'd say good idea: https://github.com/desktop/desktop

Looks like the code is at https://github.com/kactus-io/kactus and GitHub Desktop is their upstream.

Indeed, it's forked off desktop/desktop. And some of the work I've done on Kactus has been merged upstream as well, the image comparison for example.

The LICENSE file makes it explicit: https://github.com/kactus-io/kactus/pull/24/commits/0205dc6f...

The LICENSE file makes it explicit that Kactus is MIT licensed and copyright holders to at least some of the covered code include those listed. Good, that's what the license file is for when the license is MIT. It doesn't make the upstream relationship explicit though. I imagine explicit would be documenting in README or CONTRIBUTING or something like that (not at all required by the license, just informative for users and contributors).

Far ago in a space far removed from today in space and time i used svn for versioning everything. Yes it meant storing whole blobs in the folder but it worked for everything - source, documents, pictures. If one doesnt need to have versions of internals of the non-textual items then it is usually good enough. For office docs most of them support edit tracking. The only thing that was an issue was database contents but for those one can store differential logs (most mainline db supported them).

Yes its not beautiful but it is useful and it did work reliably. And best of all because of using svn and integrating TortoiseSVN into explorer (was using windows) it meant basically no new tools to learn.

Reply on news.ycombinator.com