[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can my entire home directory become a subversion working copy?

From: S. Cowles <scowles_at_ckhb.org>
Date: Wed, 14 Oct 2009 09:28:52 -0700 (PDT)

On Tue, 13 Oct 2009, Les Mikesell wrote:

> Date: Tue, 13 Oct 2009 13:03:33 -0500
> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: Harry Putnam <reader_at_newsguy.com>
> Cc: users_at_subversion.tigris.org
> Subject: Re: Can my entire home directory become a subversion working copy?
>
> Harry Putnam wrote:
>>
>>> my objective is to keep an entire, defined, development environment under
>>> svn control. this is not an all-encompassing backup. the files kept under
>>> svn control are specified in a complete list, where "complete list" refers
>>> to the configuration management construct of an explicit list that
>>> specifies each file that should be included. i have broadened the concept
>>> so that the complete list in this case includes regular expressions and
>>> sub-directories. updating the complete list is easy and the process is
>>> data-driven so its changes propogate automagically through the chain of
>>> subprocesses (commits, updates, etc). the process also requires that the
>>> svn working copy be separate from the production environment (normal
>>> working home directory). thus, working copy is just a subdir of the
>>> homedir.
>>
>> This is not meant as a criticism... I am interested in hearing more
>> about your approach... however what you wrote above comes over to me
>> as sort of gobbledeegook...
>> Like:
>>> to the configuration management construct of an explicit list that
>>> specifies each file that should be included. i have broadened the
>>> concept
>> What the heck does that mean?... I'm not really asking for an answer
>
> Sounds to me like a script that is slightly more intelligent than
> recursing through the directory doing 'svn add *' and ignoring the
> errors from the files already added. As long as you never have to
> update (i.e. changes are only happening in one location), you can
> probably manage deletes by running 'svn status' periodically and doing
> 'svn delete' on the files it shows as missing.

The basic problem I addressed was how to replicate my dev environment
on a lot of different boxes, both inside and outside a firewall.
At the same time, this bunch of files is in constant development so I
wanted them under subversion's control. My dev environment includes
such things as zsh startup scripts, gnome rc's, email (procmail,
fetchmail) startup files, etc. In other words, whatever I think I
might need to feel comfortable on a new host. (In my case, this dev
environment is cross-platform; I use it on linux, win7, bsd's, os x.)

I wanted tighter control on which files (and/or subdirectories)
would be kept under svn than simply giving a "svn add homedir".
and I wanted the flexibility to include different files/dirs on some
hosts than others.

Now, one simple use-case would be to include a homedir and explicitly
exclude the svn working copy and the .svn subdirs. That is a
straightforward regular expression in zsh. (Zsh is the scripting
language in which most of the utilities in this suite are written.)

gobbledeegook: Sorry 'bout that. Data-driven processes is just a concept
out of object-oriented design. Check out Amazon for information on
configuration management. Somewhere in the config management books you'll
find reference to a complete list. It's a term used in shrink-wrapping a
software product: every file that goes into the software product package
must be explicitly specified.

In my case, I want to specify every file that goes under svn control,
but retain the flexibility to include different files on different hosts.
Yes, it is a suite of scripts that are "slightly more intelligent than
recursing through the directory doing 'svn add *'", but no errors are
ignored, and as was stated in the first note I sent, it is constantly
used for the commit-update cycle.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407633

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-14 18:29:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.