0.6.x - detachdb in wrong place
12 messages, 17 to 20 Jun 2012. Started by grarpamp.
grarpamp (6), Greg Maxwell (3), Luke Dashjr (3)
Well, detachdb doesn't appear in the -\? help because it's stuffed under pnp, which is not set in my build. please fix for people, tx :)
#ifdef USE_UPNP
#if USE_UPNP
" -upnp \t " + _("Use Universal Plug and
Play to map the listening port (default: 1)") + "\n" +
#else
" -upnp \t " + _("Use Universal Plug and
Play to map the listening port (default: 0)") + "\n" +
#endif
" -detachdb \t " + _("Detach block and address
databases. Increases shutdown time (default: 0)") + "\n" +
#endifOn Sun, Jun 17, 2012 at 5:22 AM, grarpamp <grarpamp@gmail•com> wrote:
Quoted text (3 lines)
> Well, detachdb doesn't appear in the -\? help > because it's stuffed under pnp, which is not set > in my build. please fix for people, tx :)
It isn't inside the ifdef in bitcoin git master.
(For future reference this sort of request is probably best opened as an issue in the github issue tracker instead of posted to the list).
Quoted text (1 line)
> It isn't inside the ifdef in bitcoin git master.
Oh, hmm, well then, what is the difference or usage between these two repositories in regards to the project?
Which one are the formal releases tagged (tbz's cut) in?
Which one has the branches with the commits that will make it into the next formal release? ie: tracking along 0.5.x, 0.6.x, HEAD/master (to be branched for 0.7.x).
https://github.com/bitcoin/bitcoin https://git.gitorious.org/bitcoin/bitcoind-stable
I seem to be seeing more tags in the former, and more maintained branches in the latter?
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp <grarpamp@gmail•com> wrote:
Quoted text (12 lines)
>> It isn't inside the ifdef in bitcoin git master. > > Oh, hmm, well then, what is the difference or usage > between these two repositories in regards to the project? > Which one are the formal releases tagged (tbz's cut) in? > > Which one has the branches with the commits that will > make it into the next formal release? ie: tracking along > 0.5.x, 0.6.x, HEAD/master (to be branched for 0.7.x). > > https://github.com/bitcoin/bitcoin > https://git.gitorious.org/bitcoin/bitcoind-stable
The latter is Luke's backports of security and stability fixes to otherwise unmaintained old versions.
Quoted text (5 lines)
>> https://github.com/bitcoin/bitcoin >> https://git.gitorious.org/bitcoin/bitcoind-stable > > The latter is Luke's backports of security and stability fixes to > otherwise unmaintained old versions.
Ah ok, coming from cvs/svn, it's a bit different to find things. There's something to be said for maintenance of pior branches. Though I see some things I can use in github and my work would be more useful there, so maybe I'll stwitch to that from gitorius/0.6.x.
Presumably the github/0.6.2 branch is safe for production?
What degree of caution about wallet eating should be made for those using github/master?
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
Quoted text (12 lines)
> >> https://github.com/bitcoin/bitcoin > >> https://git.gitorious.org/bitcoin/bitcoind-stable > > > > The latter is Luke's backports of security and stability fixes to > > otherwise unmaintained old versions. > > Ah ok, coming from cvs/svn, it's a bit different to find things. > There's something to be said for maintenance of pior branches. > Though I see some things I can use in github and my work would > be more useful there, so maybe I'll stwitch to that from gitorius/0.6.x. > > Presumably the github/0.6.2 branch is safe for production?
No, that was a temporary branch of what became the stable 0.6.x branch. GitHub/master is bleeding edge. For production, you usually want the stable branches/releases (which are on Gitorious).
The fix to -detachdb's position in -help was just merged to master, and should be backported sometime in the next few days.
Luke
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp <grarpamp@gmail•com> wrote:
Quoted text (1 line)
> Presumably the github/0.6.2 branch is safe for production?
0.6.2 is very widely used, more so than the other acceptably updated backports.
Quoted text (2 lines)
> What degree of caution about wallet eating should be > made for those using github/master?
I can't speak for anyone but myself:
I don't run master on wallets with large amounts of (non-testnet) coin in them, except for a few times when I needed access to this feature or that or just in a isolated capacity for testing. In any use with real wallets I'd be sure to have good backups that never touched the new code.
We have at various times had bugs in master that would corrupt wallets (though IIRC not too severely) and have bugs that would burn coin both in mining and in transactions (though again, I think not too severely). My caution is not due to the risk being exceptionally great but just because there is probably no remedy if things go wrong, this caution is magnified by the fact that we don't currently have enough testing activity on master.
Testnet exists so that people can test without fear of losing a lot of funds and with the 0.7.0(git master) testnet reboot it should be more usable than it has been. It would be very helpful if anyone offering bitcoin services would setup parallel toy versions of your sites on testnet— it would bring more attention to your real services, it would give you an opportunity to get more testing done of your real services, it would show some more commitment to software quality, and it would let you take a more active role in advancing bitcoin development by doing a little testing yourself that you couldn't do on your production systems.
Quoted text (3 lines)
> be sure to have good backups that never touched the new code... > We have at various times had bugs in master that would corrupt > wallets
Sorry, that's to be expected, I shouldn't have asked.
Quoted text (2 lines)
> It would be very helpful if anyone offering bitcoin services would > setup parallel toy versions of your sites on testnet...
Good point.
Quoted text (1 line)
> we don't currently have enough testing activity on master.
I usually test compile / report current and stable of things I use.
So I get that github/master is the obvious top of things. But in looking at where the tags are between repositories, it's still not clear to me what the workflow is.
Example...
There are these release tarballs on sourceforge, which all have tags in github, yet no tags in gitorious. There are no 'x' branches on github, yet there is one release applicable branch on gitorious.
I guess I'd expect to see, that if as hinted by Luke that gitorious has the stable trees, that there would be release tags there, laid down at some comfy point in time on the 'x' stable branches there. (The stable branches inheriting new code from master). But there are no such tags.
And the releases/tags seem to magically appear from nowhere on github :) Again, I'm trying to extricate myself from CVS here.
# sourceforge tarballs 0.6.0 0.6.1 0.6.2 0.6.2.2
# github branches remotes/origin/master 432d28d Merge pull request #1477 from gmaxwell/master remotes/origin/0.6.2 40fd689 Bump version to 0.6.2.2 for osx-special build # github tags v0.6.0 v0.6.1 v0.6.2 v0.6.2.1 v0.6.2.2
# gitorius branches remotes/origin/0.6.0.x d354f94 Merge branch '0.5.x' into 0.6.0.x remotes/origin/0.6.x 5e322a7 Merge branch '0.6.0.x' into 0.6.x # gitorious tags v0.6.0.7
On Monday, June 18, 2012 3:27:52 AM grarpamp wrote:
Quoted text (3 lines)
> So I get that github/master is the obvious top of things. > But in looking at where the tags are between repositories, > it's still not clear to me what the workflow is.
Workflow is all new development takes place in master during release windows. Eventually, those windows close and master is cleaned up and bugfix'd for the next 0.x release. Occasionally, when 0.N.0 has some problem before the next release window opens, Gavin will use it to roll a 0.N.1 (and recently even a 0.N.2 and 0.N.2.2). Once the release window for the next 0.N version opens, I import the (last bugfix-only commit after the final 0.N.M release made in master) into the stable repository as the 0.N.x branch, and begin applying backports. When there's significant backports, I'll tag another 0.N.M from the branch and possibly release Windows binaries. Usually this happens around the same time as master becomes the next 0.N.0 release.
Quoted text (11 lines)
> Example... > > There are these release tarballs on sourceforge, which all have > tags in github, yet no tags in gitorious. There are no 'x' branches > on github, yet there is one release applicable branch on gitorious. > > I guess I'd expect to see, that if as hinted by Luke that gitorious > has the stable trees, that there would be release tags there, laid > down at some comfy point in time on the 'x' stable branches there. > (The stable branches inheriting new code from master). But there > are no such tags.
I guess I've been neglecting to update the stable repo with releases tagged in master. It should be fixed now.
Luke
Quoted text (1 line)
> Workflow is ...
Thanks very much, I think that helps me/others. I did not realize there were release windows in master and thought it more as the typical full time dev slush. That also explains the presence of all the release tags in github repo. And even, in a divergent way, the presence of github/0.6.2 as path to gitorius/0.6.x. And I agree with the (last bugfix after release) -> import/maintain model, it would be similar in solo repo.
Quoted text (2 lines)
> I guess I've been neglecting to update the stable repo with > releases tagged in master. It should be fixed now.
Yes, that has helped! Now git'ers can easily compare the release tags to stable 'x' branches on gitorious. I don't know how to do that across repos yet, save manuel diff of checkouts from each, which would have been required prior to this update you made.
Also, these declarations of defunctness help sort out too.
# git branch -vv -a "This stable branch is no longer maintained."
Ok, so for my works I will now track github/master (edge) and gitorious/0.bigN(eg: 6).x (stable) against gitorious/bigTagRelease (latest public). Thanks guys, and Luke :)
I hope other with similar questions find this thread. Apology for subverting its subject somehows.
On Monday, June 18, 2012 8:09:56 AM grarpamp wrote:
Quoted text (7 lines)
> > I guess I've been neglecting to update the stable repo with > > releases tagged in master. It should be fixed now. > > Yes, that has helped! Now git'ers can easily compare the release > tags to stable 'x' branches on gitorious. I don't know how to do > that across repos yet, save manuel diff of checkouts from each, > which would have been required prior to this update you made.
This is the work model I use: git clone git://github.com/bitcoin/bitcoin.git cd bitcoin git remote add stable git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git git remote add personal git@github•com:YOURNAME/bitcoin.git
With this, you can use "git fetch --all" to update your copy of the remote branches, and access them as "origin/master", "stable/0.6.x", etc; and push personal branches using "git push personal <branch>"
Luke
Quoted text (1 line)
> This is the work model I use:
Will try all these things out this weekend. Thanks.