George P Nychis wrote:
I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches
What does everyone think about user directories?
/
/projects
/projects/project_name
/projects/project_name/trunk
Hi,
I thought I'd just drop some lines too (without actually being helpful :).
On Fri, Sep 12, 2008 at 12:13:26AM -0700, Firas A. wrote:
I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches
I
Hi Community,
I want to share my 2 cents too,
George Nychis Wrote:
I agree, svn+trac is the way to go here. It's what everyone is already
familiar with, and it works great.
I agree too.
I was thinking that the SVN structure should be something like:
/
/project_name
The slightly longer response:
I think these are all great ideas, and I think they'd be a valuable
contribution to the GNU Radio community. CPAN (The Comprehensive Perl
Archive Network) and CEAN (the Comprehensive Erlang Archive Network) are
but two implementations of similar ideas.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 11, 2008, at 1:14 PM, George P Nychis wrote:
The slightly longer response:
I think these are all great ideas, and I think they'd be a valuable
contribution to the GNU Radio community. CPAN (The Comprehensive
Perl
Archive Network) and
My impression is that SVN+trac is working pretty well. My experience with
git has been everything but positive; maybe because I _still_ haven't
found that simple, elegant reference that explains it well, but I'm just
not a fan. Plus it would be nice to keep the same model as the existing
Johnathan Corgan wrote:
On Mon, Aug 25, 2008 at 10:43 AM, Dan Halperin
[EMAIL PROTECTED] wrote:
On this note, but slightly tangential, there are a bunch of third party
gnuradio plugins that are not being kept up to date and even no longer work
with gnuradio without significant changes.
On Tue, Sep 09, 2008 at 02:21:19PM -0400, George Nychis wrote:
Additionally, 3rd party support is a great way to gather code for someone
to look at what else is available out there. For example, there was
multi-path code someone posted a while back that they had to go through
some hassle
Just putting my 2c in: I also think it's a great idea to have a 3rd party
repository, independently of license, the existence of a maintainer etc
The main gain of this would be a demonstration of the strength of GnuRadio.
Here's what I mean:
Today, if someone who has no clue about what GnuRadio
On Tue, Sep 09, 2008 at 11:45:15AM -0700, Eric Blossom wrote:
On Tue, Sep 09, 2008 at 02:21:19PM -0400, George Nychis wrote:
Additionally, 3rd party support is a great way to gather code for someone
to look at what else is available out there. For example, there was
multi-path code
On Mon, Aug 25, 2008 at 10:43 AM, Dan Halperin
[EMAIL PROTECTED] wrote:
On this note, but slightly tangential, there are a bunch of third party
gnuradio plugins that are not being kept up to date and even no longer work
with gnuradio without significant changes. (E.g., top block vs flow
11 matches
Mail list logo
