diff options
author | W. Trevor King <wking@drexel.edu> | 2009-12-13 06:19:23 -0500 |
---|---|---|
committer | W. Trevor King <wking@drexel.edu> | 2009-12-13 06:19:23 -0500 |
commit | 4d057dab603f42ec40b911dbee6792dcf107bd14 (patch) | |
tree | 9a73459aa160e3c96f4893b132543f412ca6e97f /.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body | |
parent | dff6bd9bf89ca80e2265696a478e540476718c9c (diff) | |
download | bugseverywhere-4d057dab603f42ec40b911dbee6792dcf107bd14.tar.gz |
Converted libbe.storage.vcs.base to new Storage format.
Diffstat (limited to '.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body')
-rw-r--r-- | .be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body | 87 |
1 files changed, 0 insertions, 87 deletions
diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body deleted file mode 100644 index 5f55127..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body +++ /dev/null @@ -1,87 +0,0 @@ -On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: -> On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: -> > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: -> > > 1. is there any way to aggregate over multiple public branches in order -> > > to get the complete bug state -> > -> > Keeping the bug data with the source helps synchronize bug state and -> > source code. Bug state in branch A may not apply to branch B. Some -> > people like to weaken this source-bug linkage by keeping their bugs in -> > a branch all by themselves (ditz [http://ditz.rubyforge.org/] -> > currently supports this workflow). It sounds like you want to move -> > from "bugs with code" to "bugs and code in separate branches". We -> > don't have an easy way to do that in BE at the moment, since -> > version-control systems like Git have a single working branch at a -> > time (I think :p). What VCS are you using as a backend? -> -> the basic idea is to take a look at all public branches (for exaple all -> on lp/bitbucket/github) in order to tell the user of a webinterface that -> bug foo is fixed in branch xyz, and if its merged to the main branch - -Hmm. - -> > > 2. is there any model for storing bigger files at a central place (for -> > > some of my bugs i have multi-megabyte tarballs attached) -> > -> > be comment ID "See the tarball at http://yourpage/something.tar.gz" -> > Then to grab the tarball, you'd use: -> > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` -> > to grab it. -> so the basic idea is to do it completely self-managed - -Well, it's going to be managed by somebody ;). So far I'm not -convinced enough for the manager to be me, so I'm suggesting it be you -:p. - -> and have have heterogenous sources of extended data? - -I assume "extended data" here refers to your tarballs. What sort of -homogenous source did you have in mind? The comment body is currently -just a binary blob for non-text/* types, otherwise it's text in -whatever encoding you've configured. - -On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: -> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: -> -> > i want to see the combination of the bug data of all branches -> -> How is a tool to determine the set of “all branches”? The distributed -> VCS model means that set is indeterminate. - -He could just make a list of branches he likes. - -Ronny, are you looking to check bug status across several repos on the -fly, or periodically run something (with cron, etc.) to update a -static multi-repo summary? - -The easiest implementation I can think of would be to keep local -branches (on whatever computer is hosting your web interface) -following your favorite repos. - proxectX/ - |-- repoA - |-- repoB - `-- repoC -You'd pull upstream changes with a cron job. -Listing bugs would be something along the lines of - projectX$ for repo in * - do - pushd $repo - be list - popd - done | sort | uniq -Then to show bug status you would have something like - projectX$ for repo in * - do - echo $repo - pushd $repo - be show ${BUGID} - popd - done -For a web frontend, you'd want to translate that to python/libbe. - --- -This email may be signed or encrypted with GPG (http://www.gnupg.org). -The GPG signature (if present) will be attached as 'signature.asc'. -For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy - -My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt |