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
/projects/pr
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/bra
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
> /project_
> 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
>
-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 CEAN
>
> 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 ide
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
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 ca
On Tue, Sep 9, 2008 at 11:21 AM, George Nychis <[EMAIL PROTECTED]> wrote:
> Maybe an additional SVN is what we need. Maybe a GIT repo. A wiki so that
> people can provide some information about their code. We need something. I
> don't care of its officially supported by GNU Radio or not, but I
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 has
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. (E.g
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 gr
12 matches
Mail list logo
