Re: [Sks-devel] hg repo existence etiquette post-merge?

[John Clizbe]

Phil Pennock wrote:
> While I've used git/hg a bit, before today I hadn't dealt with creating
> server-forked repos and issue pull requests.
> 
> That part of the process is clean and simple.  But none of the docs I'm
> finding describe what happens *next*, how do you clean up?

Just delete it if you want. It's pretty easy to just update your fork on
Bitbucket and then clone a local copy again. I guess it depends on how much
work you plan to do.

> I know that for git-like models, and I assume mercurial too, a
> single-instance store reduces the "cost" of the repo to the metadata
> about the repo and, for each branch in the repo (ie master) an id tag
> referencing the commit which represents the tip of the branch.  So
> leaving the repo there isn't really consuming significant resources.

Repo clones are so cheap in terms of resources, there's not much use for
branches, especially when everything is merged back onto the default branch.
When I did the white space cleanup, I just cloned my own local copy, then
pushed the cleanup to my local repo and that to Bitbucket.

> On the other hand, it's a fork which will "decay" uselessly for months
> at a time, and if someone contributes patches to many projects, one will
> just build up a list of old repository forks.  I do contribute patches
> to all sorts of projects, just normally via bug-trackers or email.

I guess every project is different. Kristain and and I keep copies of each
other's SKS repo as well as the main trunk maintained by Yaron. We can then
pull updates from each other fairly easily.


> Is there a consensus on how to manage this repos?  Just leave them and
> don't worry about it?

You can just leave it if you'd like. Or just as easily delete it, and when you
want to do more work, do a PR from skskeyserver/sks-keyserver to your
Bitbucket server fork and then clone that to your local working repo.

-John