Thank you for your response,
The problem with keeping a versioned list of bugs in a file is that it
only allows you to update the list in the revision that relates to the
day you found the bug, and not the day you caused the bug.
Example:
The head of /trunk is at revision 500, I have three
On 13/01/2011 20:08, Ryan Schmidt wrote:
On Jan 13, 2011, at 10:46, Jonathan Oulds wrote:
consider a project with many branches and tags, now imagine that a bug is
discovered to have been introduced at an early stage of the project e.g.
revision 100. All branches taken after revision 100
Where is the bug file versioned? I think that is the point. In my opinion it
should not be versioned across branches because that would be a headache.
Hence it should not be placed under the trunk and you might create a new
directory bugs at the same level that trunk, tags and branches. In that
Guten Tag Jonathan Oulds,
am Donnerstag, 13. Januar 2011 um 17:46 schrieben Sie:
Currently we track bug fixes by including a reference number within the
commit message, I'm sure this is common practice.
If you already use a bug tracker, doesn't that provide a mechanism to
file bugs against
We do use Bugzilla to track issues, you are correct that you can file
the bug against multiple branches and we do.
However, what if a branch is created after the bug has been added to
Bugzilla. Someone would have to manually inspect the revision at which
the branch was taken and create
Okay, I see what you are driving at here.
We write a script that takes the branch URL plus the buglist file, the
script performs an svn log -g -v to get a list of all the revision
numbers that went into that branch then compares those against the head
revision of the buglist file.
Yes, that
Dear List,
Replying to myself in the hope this may catch some more eyes. More info
inline below...
-Original Message-
From: Cooke, Mark
Sent: 12 January 2011 11:42
Subject: rejected Basic challenge for one user only (Win/apache)
Hello,
We use TortoiseSVN from windows XP SP3
Hi Folks,
i want to merge a branch into trunk. For that i got the first revision
of the branch with (svn log --stop-on-copy = 2854). Now i want to
merge with svn merge -r 2854:3143 ^/branches/mybranch . in a trunk
working dir. Svn now tries to merge the trunk not with the newest
files in the
On Fri, Jan 14, 2011 at 02:12:56PM +0100, peter.schwei...@gmail.com wrote:
Hi Folks,
i want to merge a branch into trunk. For that i got the first revision
of the branch with (svn log --stop-on-copy = 2854). Now i want to
merge with svn merge -r 2854:3143 ^/branches/mybranch . in a trunk
Thx very much, that solved my problem :-)
Strangely, until now i was able to merge branches into trunk without
this option
Regards,
Peter
On Fri, Jan 14, 2011 at 2:42 PM, Stefan Sperling s...@elego.de wrote:
On Fri, Jan 14, 2011 at 02:12:56PM +0100, peter.schwei...@gmail.com wrote:
Hi
On Fri, Jan 14, 2011 at 02:53:11PM +0100, peter.schwei...@gmail.com wrote:
Thx very much, that solved my problem :-)
Strangely, until now i was able to merge branches into trunk without
this option
You got lucky. The --reintegrate option is quite important.
See
This is a continuation of my experiences described in the What SVN
command-line client distro should I get to work properly with SVN 1.4.x
on the server? subject.
My SVN server is running version 1.4.x. I'm using the latest Subversive
in Eclipse, but the connector associated with SVN 1.5.6.
On Fri, Jan 14, 2011 at 2:06 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote:
Just so we're clear here, I have these projects checked out in Eclipse,
but not in the same directory that I'm trying to do the command-line
checkout. I'm trying to do a separate checkout of these projects, just
using
-Original Message-
From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com]
Sent: 14 January 2011 19:07
To: Tony Sweeney; users@subversion.apache.org
Subject: RE: SVN 1.6.15 checkout fails on particular file
-Original Message-
From: Tony Sweeney
On Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote:
This is a continuation of my experiences described in the What SVN
command-line client distro should I get to work properly with SVN 1.4.x
on the server? subject.
My SVN server is running version 1.4.x. I'm using the
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: Friday, January 14, 2011 11:35 AM
To: KARR, DAVID (ATTSI)
Cc: users@subversion.apache.org
Subject: Re: SVN 1.6.15 checkout fails on particular file
On Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI)
On Jan 14, 2011, at 14:19, KARR, DAVID (ATTSI) wrote:
Hmm. I think I found a big clue. When I do the checkout, I'm giving it an
alternate name. The svn checkout doc is clear that this is legal. In
other words, I'm doing svn checkout svn:... desiredname.
I've tried doing this several
Just a short note to extend an offer of free tickets to any of the
Subversion committers who might want attend any of the Subversion Live 2011
events in San Francisco (Silicon Valley), Boston, MA or London (England).
More info is here: http://goo.gl/ogtdE
You will need a special discount code to
On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
I then looked at the full local path this file would represent, and the
entire path is 260 characters long. I would think if there's any threshold,
it would be at 255, not 259.
Any idea what's going on here?
The usual maximum path
-Original Message-
From: David Huang [mailto:k...@azeotrope.org]
Sent: Friday, January 14, 2011 1:29 PM
To: KARR, DAVID (ATTSI)
Cc: users@subversion.apache.org
Subject: Re: SVN 1.6.15 checkout fails on particular file
On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
I
Hi,
I've had some issues compiling Subversion and APR in my Ubuntu environment
(the below output is done from /trunk - I haven't tried a 1.6.x branch yet).
Running ./autogen.sh and ./configure work correctly, however I get the
following error when running 'make':
-- making all in apr
Apologies, I also had to make the same change to apr/build/apr_rules.mk:38.
---
Daniel Becroft
On Sat, Jan 15, 2011 at 8:45 AM, Daniel Becroft djcbecr...@gmail.comwrote:
Hi,
I've had some issues compiling Subversion and APR in my Ubuntu environment
(the below output is done from /trunk - I
On Fri, Jan 14, 2011 at 3:53 PM, krueger, Andreas (Andreas Krüger,
DV-RATIO) andreas.krue...@hp.com wrote:
Hello, Johan and all,
first, for the record, here is another comparison between
binary and text merge performance, this time with the files
generated by my script (repeated below):
KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800:
-Original Message-
From: David Huang [mailto:k...@azeotrope.org]
Sent: Friday, January 14, 2011 1:29 PM
To: KARR, DAVID (ATTSI)
Cc: users@subversion.apache.org
Subject: Re: SVN 1.6.15 checkout fails on particular
-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Friday, January 14, 2011 4:20 PM
To: KARR, DAVID (ATTSI)
Cc: David Huang; users@subversion.apache.org
Subject: Re: SVN 1.6.15 checkout fails on particular file
KARR, DAVID (ATTSI) wrote on Fri, Jan 14,
Johan Corveleyn wrote on Fri, Jan 14, 2011 at 23:52:10 +0100:
Ok, after rereading this thread, I'm starting to understand what you
mean: why would merge perform an expensive diffing algorithm while
it can just be 100% sure that it can simply copy the contents from the
source to the target
On Jan 14, 2011, at 6:31 PM, KARR, DAVID (ATTSI) wrote:
I'm not sure what you mean. You're saying that Subversive in Eclipse is
referencing absolute paths, but using the command line client is using
relative paths? Assuming that's the distinction, is there some way I
could use the
I had selected an option to 'accept their copy always' during svn
conflict. How do I remove/clear this option? Also, is there any guide
that explains these conflict actions/options?
Thanks,
CS.
28 matches
Mail list logo
