

Dropbox + git = Designer Luv - dko
http://pivotallabs.com/users/ken/blog/articles/1637-dropbox-git-designer-luv

======
yuvadam
Do yourself a favor and get a real git repository. Using dropbox is indeed
super easy but has two major caveats:

1\. Git is agnostic to updates to the repo, as dropbox is not a supported
transport method (as opposed to SSH for example). So, for example, git hooks
won't work.

2\. Dropbox is extremely susceptible to repo corruption in case of
simultaneous updates. Restoring a corrupt repo is not a pleasant task.

For your sanity - don't do it.

~~~
fryguy
What I usually do is have multiple repos, one per machine I'm working on. This
way they are write-once, read-many so you don't ever have dropbox merge
conflicts. It's a bit more overhead, but safer. It's even "easier" to get the
semantics right in bazaar due to the branch-as-a-folder paradigm rather than a
repo-as-a-folder design of git, although I don't really want to devolve to a
"my scm is better than your scm" debate.

------
enra
At this time and age, I think designers should learn how use git. It's a tool
like anything else.

Specially if your only concern is updating the images, the process should be
pretty straightforward, you don't need to learn anything advanced.

~~~
mtogo
This attitude that everyone should be a programmer bothers me. The designer's
job is to design, and it's the programmer's job to integrate the designs.

Why don't you learn photoshop and how to do basic design? That way you don't
need to ask the designer to do minor tweaks.

It doesn't work. If you've never used version control, "just learn git" can be
a multi-week project. If you've never done design, "just learn photoshop" is
the same.

Each person is on a team to do a specific job, let them do their jobs.

~~~
bretthopper
Since when is learning/using git "being a programmer"?

A designer's job is to design and a programmer's job is to program. Both of
those jobs require tools to make their jobs easier.

I'm sick of designers getting away with things programmers never would in
their jobs. Programmers learn skills such as: organization (files and
directories), communication (comments), workflow management (version control),
etc. In my experience with designers, none of them care about things like
that. You'll see 5 versions of PSDs filled with Untitled layers and no logical
grouping.

These are things that are just expected of programmers and they should be
expected of designers as well.

~~~
sfgfdhgfdshdhhd
I would be happy if my designer gave me untitled layers. I usually have to use
the magic wand to cut out layers from a flat picture myself. Very fun when
there are gradients, drop shadows and similar stuff on a jpg-compressed image
T_T In the end I'm essentially redoing all the work the designer did.

~~~
lovskogen
Sounds like a great guy to work with. Why do you?

------
danieldk
Given how often I get synchronization conflicts on regular files with Dropbox,
I would be quite wary to use it to put and synchronize repositories there. The
problem is (obviously) that Dropbox is really a local synchronized folder, so
a Git push will only be reflected on Dropbox if there is an opportunity to
sync. So, if you have mobile coworkers, it's easy to mess up things.

Given that there are many companies who offer repository hosting for just a
few dollars per month (also for teams), I cannot see why one would go this
route.

~~~
rodh257
I think the main advantage here is the designer doesn't need to learn git,
they just work away on a Dropbox folder without knowing it's a git repository.
Additionally, the main git repository doesn't need to be in dropbox, just the
designers remote.

~~~
danieldk
As someone else in this thread mentions, I think version management is
becoming indispensable for the modern designer, and also feasible given the
prevalence of vector graphics.

Besides that, there are some great, easy to use git clients (Tower, GitBox,
SmartGit). I have non-CS colleagues who adopted git in no-time with SmartGit
(for LaTeX documents).

~~~
gigawatt
> and also feasible given the prevalence of vector graphics.

As a designer who has had git on his "To Learn" list for way too long, can you
explain what you mean by this?

~~~
gigawatt
Ah, so it's a file-size issue. Thanks to both of you for explaining.

~~~
marcomonteiro
Git, like most versioning systems works by adding a file to a repository. Then
subsequent changes are added to the repository by saving only what has changed
in the file.

In the case of a bitmap image think of a grid made up of pixels. Each pixel is
stored on the file as binary data (0's and 1's). Anything that affects that
pixel will change it's value in the file.

With a vector file there aren't pixels necessarily. The drawing is saved as
shapes and those shapes have properties. These shapes and their properties are
actually saved as text (sort of like HTML markup).

So as the file changes the changes in those various file types are more
drastic. With a bitmap there will be greater changes so overall more space is
used to store the file and it's history. Also, because it's binary it's
difficult to see the changes in the actual file (without opening it in a photo
editing program). With a vector file only small amounts of text would be
changing and you can literally see the changes in the file and make sense of
it.

Hope that helps.

~~~
gigawatt
Very much so, thank you. So it's more how the data is stored and updated in
the different kinds of files. I definitely had the basic gist of raster vs.
vector, but had no idea how it could affect something like version control in
this way. Very interesting.

~~~
marcomonteiro
Yes basically. Your repository could grow faster using binary files but it's
still worth it to have a version history. Even if for nothing else other than
to be able to see how something evolved.

------
leejoramo
What are the real advantages of using version control from the designer point-
of-view?

In most cases, a good backup system is what they need. Use Apple's Time
Machine or Crashplan and backup every 15 minutes automatically.

From a programmers point of view VC is great. We actually have the tools to
deal with different versions of text files: find differences, resolve
conflicts, merge, split off new versions, etc.

And designers? What do they get beyond a more complex and opaque form of
Backup. Sure it makes it easier to get the designers output into our
programmers workflow, but the way this is usually sold is a Pain in the
designers backside with no real benefit.

If programmers want to win over designers to version control, we need to sell
them on real advantages. We need to show them tools like pixelnovel's timeline
that integrates SVN diretly into Adobe CS and provides an in app version
viewer. Or Kaleidoscope.app which allows the visual comparison of image (and
text!) files.

    
    
        http://pixelnovel.com/   (SVN only)
        http://www.kaleidoscopeapp.com/   (Git, Mercurial, SVN & Bazaar)
    

However, even these tools only scratch the surface of the power that
programmers gain from the pain of version control.

~~~
cpeterso
Designers need more than just backup. They work with binary files that would
need specialized diff and merge tools. They need to share files with (non-
technical) clients.

PixelNovel looks interesting, but it seems mostly focused on "timelines" for
single users, not teams.

------
lucasr
Hylke Bons wrote a very nice git-based Dropbox alternative with focus on
collaboration called SparkleShare (<http://www.sparkleshare.org>). It's still
in beta state but a few members of the GNOME design team are already using it
to collaborate.

------
mullr
What's the difference between this and just using github? I think it's just
the daemon-ness of dropbox. It would be cool to have something similar for
arbitrary git repos that runs 'git fetch' periodically in the background. (or
something fancier, if you want to scale it out) That keeps the conflict
management at the git level, and you aren't keeping history of history
anymore.

~~~
tzs
If you don't want your repositories public, price is a big difference. All of
my repositories would fit in 10% of my free Dropbox space. It would cost
$100/month to put them on Github.

Github's pricing is based on the number of repositories. Dropbox's is based on
the amount of storage used.

~~~
okaramian
You could set up a gitosis server if you have access to your own server of
some sort and don't mind administering it.

I have a linux VM on my main computer that is accessible to the outside world
with gitosis on there and it's pretty great for a private git repo.

~~~
fr0sty
Gitosis is obsolete.

If you are starting frsh, set up gitolite servers instead. Gitolite is
actively maintained and has more features and better documentation.

------
mgrouchy
I regularly work across multiple computers(all macs, but 2 desktops and my
laptop), so I actually put my virtualenvs in my Dropbox and then they contain
git repositories. So I have my full environment installed on all the computers
all the time.

You do have to install git, virtualenv and pip on all the computers, but thats
not too much to ask.

------
migueldeicaza
The open source SparkleShare gives users the same feel of Dropbox, while using
Git as its backing storage:

<http://www.sparkleshare.org/>

It currently has native clients for Linux and Mac, with Windows coming soon.

------
flexterra
Super cool idea. I will try this with a client's design team. They already use
and love dropbox.

