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

2009-05-13 Thread Ken Bloom
On Sat, May 9, 2009 at 11:15 AM, martin f krafft madd...@madduck.net wrote:

 also sprach Chanoch (Ken) Bloom kbl...@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.

Less likely than when git merges text files, source code, uncompressed
XML, and the TeX files that many computer scientists use for their
writing.

--Ken
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


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

2009-04-20 Thread Rustom Mody
On Mon, Apr 20, 2009 at 2:04 AM, Chanoch (Ken) Bloom kbl...@gmail.comwrote:

 On Sun, 2009-04-19 at 16:40 +0200, W. Kaplan wrote:
  Hi all,
 
  I just recently started giving version control systems another go. I'm a
  humanities grad student and not a programmer, so I assume that my needs
  are a little different from those for which these tools were written.
  However, the same applies for managing your whole home directory, so I
  think this list is a good place to ask for opinions.

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


From Odt article on wikipedia:

A basic OpenDocument file consists of an
XMLhttp://en.wikipedia.org/wiki/XMLdocument that has
document as its root element. OpenDocument files can also take the format
of a ZIP http://en.wikipedia.org/wiki/ZIP_%28file_format%29 compressed
archive containing a number of files and directories; these can contain
binary content and benefit from ZIP's lossless
compressionhttp://en.wikipedia.org/wiki/Lossless_compressionto
reduce file size. OpenDocument benefits from separation
of concerns http://en.wikipedia.org/wiki/Separation_of_concerns by
separating the content, styles, metadata and application settings into four
separate XML files.

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
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


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

2009-04-19 Thread W. Kaplan
Hi all,

I just recently started giving version control systems another go. I'm a
humanities grad student and not a programmer, so I assume that my needs
are a little different from those for which these tools were written.
However, the same applies for managing your whole home directory, so I
think this list is a good place to ask for opinions.

I tried using subversion several times over the past view years but
never got the hang of it. The reason why I was motivated again is that I
have a second computer now with which I want to synchronize my files.


Initially I simply set up one big git repository in $HOME. I didn't
really care about having a history because I still have my tried
rsnapshot setup in place. After being surprised by how well this worked
I read a little more about the subject (including this mailing list).

That made me try to split things up into smaller repositories as is
generally recommended. While I kind of see the point in doing so, I'm
having trouble to move away from big repositories altogether. Let me
just outline what I'm doing so far and why:

1) a git repository in $HOME for selected dotfiles and the Desktop:

I'm not yet concerned with versioning /all/ my dotfiles and
synchronizing specific ones to specific computers like some of you do. I
only add the ones I want to have on both computers.

2) a single big repository in ~/Documents:

This is me trying to find a balance between a thousand and few
repositories. This repository's main purpose is also synchronizing and
the idea is not to rely on it for versioning. I like to think of it as
an archive instead, because I'm not going to work with it (e.g. create
branches etc.). However, in rare cases it might come in handy to have
older versions of files.

3) several small, specific projects inside ~/Documents

I thought I would do things right for specific projects (e.g. a thesis
paper) and create repositories for each one. I put those active
projects into ~/Documents/git-projects/, that I ignore in the big
Documents repository. Once a project is finished I could put the .git
directory into a tar archive and move the whole directory to another,
more buried location in ~/Documents. The finished/final versions of the
files would then be added to the big ~/Documents repository including an
archive of the .git directory for whatever future purpose. Henceforth I
wouldn't have to pull that repository on the 2nd computer anymore since
the file's final versions are in the Documents archive repository.


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. From what I
understand it would be hard to work with just a subdirectory as if it
was it's own repository. I think, however, that I should be fine if I
don't want to do that, but only use it as an archive (see above). In the
rare case for when I have to retrieve a file from it I would probably be
okay with a messy commit log. Am I missing other possible problems here?

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.


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.


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 tried to use Unison, by the way, but that did not go so well. I had
trouble setting up merging and was worried about not having a history
for a hard reset in case a merge went wrong.

I'm really looking forward to seeing some reactions.

Thanks for reading.

___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home