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


Re: Version control system better suted than SVN

2009-04-19 Thread Chanoch (Ken) Bloom
On Sun, Apr 19, 2009 at 02:55:28PM -0700, Eric Hanchrow wrote:
 On Sun, Apr 19, 2009 at 1:03 PM, Chanoch (Ken) Bloom kbl...@gmail.com wrote:
   * Git keeps a local repository with full history in your working
 directory. This means at least two copies of everything are
 stored.
 
 Git's compression is good enough that I'd be surprised if this were a
 problem in practice.
 
 On the other hand, git too uses SSH for write access, so I suspect
 it'll get hung up there.

It appears that git supports WebDAV for pushing over HTTP(S) as well.

See 
http://www.xiaoka.com/blog/2008/04/13/git-repository-over-http-webdav-with-nginx/
 
which talks about how to configure a certain web server for WebDAV and
Git. I didn't see anything suggesting out of the ordinary patching or
configuration was necessary on the client side of things.

--Ken

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home