I'm starting to switch to git at work, and I'm rethinking my usual new
project workflow layout synergy hashtag a bit.
(Gah.)
What I'm thinking about is something like this:
Decide I need to work on a new project that should be in revision
control. (Question: when should you not put a project in
revision control? Answer: when you're dead; it will fuck with the
commit logs.)
Run a script.
The script will:
Prompt for a project name and a one-line description
Check out git://git.example.com/newproject, which will contain:
After this entry about the difference between push and pull for
Mercurial, and how that doesn't fit with the way I instinctively want
to use a repository, it's interesting to read Ted Tso responding
to a similar complaint from a git user. Tso explains the discrepancy
well:
Part of the problem here is that for most git workflows, most people
don't actually use "git push". ....in most large projects, the number
of people [who] need to use the "scm push" command is a very small
percentage of the developer population, just as very few developers
have commit privileges...
Ah, but in a distributed SCM world, things are more
democratic....While this is true, the number of people who need to be
able to publish their own branch is small....
There is one exception to this, of course, and this is a developer
who wants to get started using git for a new project which he or she
is starting and is the author/maintainer, or someone who is
interested in converting their project to git.
The whole entry, plus the comments, are worth reading.
Nicks' post on customizing your home was interesting. Over the
last year or so, I've been slowly improving the way I do this. My
results have been mixed, probably because of the way I use
Mercurial.
So I've got a repo to keep my dotfiles. There's a truly awful script
that will symlink the real files to the repo, and doesn't clobber the
originals more than one time out of three. I clone to work, or to a
laptop, and start customizing. Overall, I feel like this should
work…but it's decidely awkward.
Let's take the case of bash init files. I've got mine divided into
.bashrc and .bashrc_local. The latter, as you'd expect, is
machine/situation-specific — ssh aliases, commands for work,
etc. .bashrc sets various aliases and functions that are unlikely to
change. Just before exporting all the environment variables,
.bashrc_local is sourced, which gives me a chance to override
anything.
.bashrc should be in the repo — no question about that. But
.bashrc_local should be there too, since I may clone my repo at work
(say) to another filesystem. Since Mercurial is distributed, there's
no problem with this — except when it comes to merging things back
home. Since I think about home as The One True Repo, I want to keep
everything there. But usually I've run hg push ssh://home, which
promptly clobbers .bashrc_local there (at least when I do an hg
update. Or if I merge from home, I end up creating new heads in my
repo, and a multi-headed repo can't be pushed. (I'm fuzzy on the
details; usually when this happens I bang away at it randomly until
merges happen, and swear until I'm blind.)
As outlined here, the difficulty is probably in the way I use
Mercurial and the way I've become used to SVN's (and CVS's) idea of
branches that look like directories (and are thus very, very visible
and easy for me to think about). xyld says, "I'm fed up with having to
do hg merge and not actually merge anything, but just to satisfy the
Mercurial internals." That's pretty much how I'm starting to
feel. There's the option of doing pull, rather than push, to
cherrypick the changes I want, but it's still a bit awkward for me to
think about.
I understand SVN; it fits well with my brain, which is not a
developer's. I understand hg, and I like the idea of distributed repos
for certain things. But xyld's comments about switching to git
resonate with me, and I may start trying that out.
We're going to switch from CVS to Subversion at work. I don't make a
whole lot of use of CVS, so the finer points of change management are
more academic to me than anything else. But authentication...ah,
that's a different story. Right now, Unix clients access the CVS
repository by NFS; Windows users use the pserver
protocol/authentication. NFS access does cause some problems for CVS,
but it's completely out of the question for Subversion if you use
their Berkely DB filesystem. It's okay for read-only access if you use
their FSFS (actual real filesystem files filesystem; the equivalent of
CVS' bunch of directories and files). This leads to questions about
how we'll allow access over the network, and how we'll authenticate
users. Here's my thinking so far.
Daemon + DB2
Pro: Can restrict access through file permissions to prevent access by NFS.
Con:Plain text password file. YAFPF.
svn+ssh + DB2
Pro: Secure access from home. SSH key-based authentication.
Con: The mirrored drive where the repository should be kept is available by NFS and Samba; this can't change. Since file permissions would need to be open to allow read/commit, there's nothing preventing access by NFS and resultant corruption. The other alternative is putting it on a non-mirrored drive, which isn't an option either.
Apache + PAM
Pro: Can restrict file permissions to prevent NFS/Samba access. Uses already existing FPF, and since we're not using PAM now we can eliminate AFPF. Prod to switch Samba to PAM, which would be AFPF gone.
Con: Haven't worked with A2, DAV or mod_auth_foo before. Since will need to coexist for a while with A1, possibility of calcification.
Apache + LDAP
Pro: Full buzzword compliance. One FPF to bind them all. Get ready for the groupware that will someday be coming down the pike. Can restrict file permissions to prevent NFS/Samba access.
Con: Haven't worked with LDAP, either. Will need to convert current password file rather than access directly, creating YAFPF (at least in the short term). Much bigger change, so even bigger danger of calcifictation. (Heh...I like that typo.)
I think I can do Daemon + FSFS, but I need to reread the Subversion
book (truly excellent, BTW). This might be the best way to get
things going quickly. And of course, any insights or hints are
welcome.