Best practice for Documents directory: looking for comments on my current setup

[W. Kaplan]

On 05/19/2009 10:34 PM, Chanoch (Ken) Bloom wrote:

> Keep in mind that if you have merge conflicts in your office files,
> whether OpenOffice or MS Word, git and other version control systems
> are much less likely to be able to do something sensible about merging
> them.  The reason we programmers can make it work is because we use
> text files for everything.  (Our source code is text files, our
> configuration files are text files, our scholarly papers are written
> in LaTeX...).

Thank you, for pointing that out. Fortunately I'm a Vim fanatic. As a
result I keep as much information as possible in text files. Of course,
there are files that won't merge. As long as I'm aware of those (which
isn't too hard if you're only dealing with two computers) things work
out fine.

>> 2) a single big repository in ~/Documents:
>>
>> 3) several small, specific projects inside ~/Documents
>
> Git is designed to work best for case 3, but practically everyone in
> the vcs-home community has some section of their home directory which
> works like case 2. I split mine up into several sections though, for
> example:

> In all I have 87 repositories. Only a few of those are checked out at
> any given time.

Wow, that's a lot.

I'm in the middle of fiddling with "mr" and splitting things up further,
always as far as I consider it being purposeful. For example, instead of
only having the big Documents/ repository with some topic specific
repositories in it, I also created a Documents/uni/ repository. This
also functions as a big "everything inside" repository like its parent
(and would be 2a in my initial list), but it is a little more specific.

As I go along I decide to put more and more things under actual version
control, i.e. initiate specific repositories. It's quite interesting.
Who knows, at the current rate I will have 87 repositories myself in two
weeks.

>> b) Since the ~/Documents/git-projects directory is being ignored by
>> the Documents repository I have to manually create it on the other
>> computer and manually pull the projects inside it. Right now I only
>> have to deal with 2 active projects, so I don't mind managing this by
>> hand, but what if I create more projects? Maybe that will be the time
>> to try the "mr" tool.
>
> This is what the mr tool is for.

I'm in the middle of setting it up for my repositories. It seems very
helpful so far and the configuration is less tedious than I though it
would be.

> I keep all my repositories in /home/bloom_git, then clone things into
> my home directory in /home/bloom. For me, any repository that's old
> and rarely used will only live in /home/bloom_git, and not actually
> get checked out.

That is interesting and I will consider it. Although I feel like that it
might be something for another time, just like taking greater care of
dotfiles.

>> Looking at my current approach I feel like I'm using git for several
>> different purposes: simple synchronizing (of dotfiles), synchronizing
>> and archiving (of the Documents directory) and actual project
>> management. This makes me wonder if I'm trying too hard to use one
>> tool here. Maybe there are other tools to be considered?
>
> I use git for all of these things. There are a few places where I feel
> subversion might be a better fit (a few particularly conflict-prone
> configuration files are easier to blow away local changes without
> creating the extra commits that git needs), but I'm going to make a go
> of it with git.

I feel pretty confident that git is up to the task now. I hope you (and
all the others) will keep us updated.

> --Ken

Thank you so much for your reply.