I'd add another scenario which is that every night the build system builds
whatever was checked in. This can cause extensive and confusing breakage in
the build system. The build report does indicate svn revision number and
timestamp of last commit, but one tends to look at the version number.
Before we go and invent all kinds of stuff, is this a real problem that we
need to spend resources thinking about?
Dan's original post was about 2 people who check out devel from svn may see
the same version number, but have different versions of the code. I
acknowledge that this is theoretical p
As Pete and Ryan have pointed out, it seems that the version control system
should somehow ease the burden of the developer here.
Let's look at this from the github perspective, since it is likely to be
the primary hosting mechanism for the foreseeable future. Just thinking out
loud, if R could so
On Fri, Sep 5, 2014 at 7:50 PM, Peter Haverty
wrote:
> Hi all,
>
> I respectfully disagree. One should certainly check in each discrete unit
> of work. These will often not result in something that is ready to be used
> by someone else. Bumping the version number constitutes a new release and
Hi All,
Git-svn is a nice workaround for the developer. As a user you don't want to be
installing from version control in any case. Version control is a means for
tracking changes, not for distributing software. Let the CI system protect
you from needless drama.
Typed with thumbs.
> On Sep 5
Hi all,
Just to throw in a suggestion here, I know that many people use a tool
like git-svn in this kind of situation. They want the ability to make
multiple small commits in order to save their progress, but they don't
want those commits visible until they are ready to push all at once.
This
Hi all,
I respectfully disagree. One should certainly check in each discrete unit
of work. These will often not result in something that is ready to be used
by someone else. Bumping the version number constitutes a new release and
carries the implicit promise that the package works again. This
Dan,
If that is is a hard BioC policy I'll endeavor to follow it (I do already
in the vast majority of cases), but I must say it makes the Bioc repository
much less useful from a development standpoint.
There are lots of reason to commit code that doesn't work and shouldn't yet
be deployed, from
- Original Message -
> From: "Stephanie M. Gogarten"
> To: "Dan Tenenbaum" , "bioc-devel"
>
> Sent: Friday, September 5, 2014 4:27:13 PM
> Subject: Re: [Bioc-devel] Please bump version number when committing changes
>
> I am guilty of doing this today, but I have (I think) a good reas
I am guilty of doing this today, but I have (I think) a good reason.
I'm making a bunch of changes that are all related to each other, but
are being implemented and tested in stages. I'd like to use svn to
commit when I've made a set of changes that works, so I can roll back if
I break somethi
Thanks, just a typo. Fixed in S4Vectors 0.2.1.
On Fri, Sep 5, 2014 at 12:38 AM, Hervé Pagès wrote:
> Hi Michael,
>
> I found the following bug when coercing a list to a SimpleList
> with IRanges devel (not with IRanges release):
>
> library(IRanges)
> x <- list(a=matrix(rep("a", 6), nrow=3)
This approach, writing in chunks, is the same Herve and I used for writing
FASTA in the Biostrings package, although I see that Herve has now replaced
the R implementation with a C implementation. I similarly found an
absolutely huge speed up when writing genomes, by chunking.
Best,
Kasper
On T
Hi Michael,
I found the following bug when coercing a list to a SimpleList
with IRanges devel (not with IRanges release):
library(IRanges)
x <- list(a=matrix(rep("a", 6), nrow=3),
b=array(rep("b", 24), dim=c(3,4,2)))
Then:
> sapply(as(x, "SimpleList"), class)
a
13 matches
Mail list logo
