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

[martin f krafft]

Collective reply, because this thread has been in my inbox too
long...

also sprach W. Kaplan <walter.kaplan at gmail.com> [2009.04.19.1640 +0200]:
> The problems I'm aware of are:
> 
> a) Having the big ~/Documents repository is as wrong as a single big
> $HOME repository, because it's still a lot of unrelated stuff in one
> place. I'm actually not perfectly sure why this is so bad.

It isn't, necessarily. It just means that you won't be able to pull
it apart, e.g. only take stuff related to your thesis with you on
the space-limited netbook, and still be able to use VCS as before.
If you keep it all in one repo, it's all or nothing anywhere you go.

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

Yeah, sounds like mr.

> I read about but haven't actually tried the "mr" tool yet. I don't
> think that I want to go down that road. As far as I understand it,
> I could create repositories in different places anywhere in
> Documents/ and would not have to remember them all, because "mr",
> once configured, would take care of it. While this seems nice it
> also seems inefficient to keep pulling repositories that will not
> see any new commits ever though.

With Git, you don't really notice it. Plus, mr can parallelise the
pulls, so I'd say: just do it.

> 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 think Git is fit for all those purposes.



also sprach Chanoch (Ken) Bloom <kbloom at gmail.com> [2009.04.19.2234 +0200]:
> 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.

Less likely than what? I don't know any other tool that can sensibly
merge those dinosaur formats.

> I don't expect any other synchronization system can reconcile
> these files any better though. When someone comes up with a good
> way to reconcile these files, I hope we'll steal it and integrate
> it into git.

Yeah. Git does allow for custom merge drivers.

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

If it's just local, you can use git-reset or git-rebase -i to blow
them away too...



also sprach Rustom Mody <rustompmody at gmail.com> [2009.04.20.0829 +0200]:
> Thanks to this push, good-ol MS has moved (unwillingly?) from doc (for which
> your comments above are correct) to docx that is similarly at core xml and
> hence text.
> 
> > I don't expect any other synchronization system can reconcile these
> > files any better though.
> 
> This true today.  And merging XML is not identical to merging program
> sources.  But is much closer to it than arbitrary binry data

True, in theory. If you think that we'll be able to merge two
separately-edited OOo or MS Office files anytime soon, you are
underestimating the storage format requirements of WYSIWIG editors,
and underestimating Microsoft's furious attempts to adhere to the
standard without actually implementing it. Apart, even if you could
identity the conflicts atomically, how would you alert the user to
them?



also sprach Chanoch (Ken) Bloom <kbloom at gmail.com> [2009.04.20.1532 +0200]:
> Though I've uncompressed .odt files myself to get at the XML inside,
> I've never seen one of these in the wild that wasn't ZIP-compressed, so
> as far as version control systems are concerned it's still binary data.

This wouldn't matter for Git, since Git only stores contents, even
for text files, and invokes merge drivers to combine two different
versions. For text-only files, the merge driver is just the easiest
you could conceive, which is why Git can do such an awesome job.
It's still line-oriented, so far from perfect yet.

> (I'm not even sure how the format would keep the four separate XML files
> together if they weren't zip compressed, so maybe the Wikipedia article
> is wrong or unclear.)

AFAIUI, Zip is part of the format specification.



also sprach Kelly Clowers <kelly.clowers at gmail.com> [2009.04.21.0731 +0200]:
> http://git.or.cz/gitwiki/GitTips
> 
> In git 1.6.1 or later, try this in .gitconfig:
> 
> [diff "odf"]
>       textconv=odt2txt
> 
> (unoconv might also work)
> 
> and in .gitattributes:
> 
> *.ods diff=odf
> *.odt diff=odf
> *.odp diff=odf
> 
> Note that I have yet to actually make use of this.

This can actually give you diffs in the text, but you won't be able
to make use of them, let alone merge any changes. This is because
txt2odt is missing. ;)



also sprach W. Kaplan <walter.kaplan at gmail.com> [2009.04.21.1203 +0200]:
> 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.

And? ;)



also sprach Eric Hanchrow <eric.hanchrow at gmail.com> [2009.04.19.2359 +0200]:
> If you don't mind some random company holding your data, you should
> look at http://www.getdropbox.com/ -- it's dead simple, works on *nix,
> Windows, and Mac; and it automatically keeps old versions.  No help
> for merging, though.

… until they go bankrupt and it's all gone. Or they change their
terms of service and make it impossible for you to get the data. Or
they have a super-crash and it's all gone. That could happen to you
too, sure thing. But they made sure that you could not hold it
against them. Maybe they anticipate it? ;)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
one has to multiply thoughts to the point
where there aren't enough policemen to control them.
                                               -- stanislaw jerzey lec
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20090509/8a482fea/attachment.pgp>