
Kactus: Design version control without changing tools - doener
https://kactus.io/
======
krsdcbl
"Design Version control without changing tools" ... that is, if you're on Mac
OS and your tool is sketch.

~~~
mathieudutour
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.

------
Bilters
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)

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

------
GuiA
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?

~~~
MaulingMonkey
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](https://github.com/PistonDevelopers/VisualRust/issues/302)

~~~
icebraining
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.

~~~
MaulingMonkey
> 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/](http://git-
annex.branchable.com/todo/smudge/)

------
Ethcad
The website looks exactly the same as that from GitHub Desktop:
[https://desktop.github.com/](https://desktop.github.com/)

~~~
captn3m0
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](https://github.com/desktop/desktop)

~~~
mlinksva
Looks like the code is at [https://github.com/kactus-
io/kactus](https://github.com/kactus-io/kactus) and GitHub Desktop is their
upstream.

~~~
captn3m0
The LICENSE file makes it explicit: [https://github.com/kactus-
io/kactus/pull/24/commits/0205dc6f...](https://github.com/kactus-
io/kactus/pull/24/commits/0205dc6f3144656fb225d5a45a19c1b84ed3c9ad)

~~~
mlinksva
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).

------
zoom6628
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.

