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.
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 command
KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 16:31:04 -0800:
> > -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.
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
> -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, Ja
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
On Fri, Jan 14, 2011 at 3:53 PM, krueger, Andreas (Andreas Krüger,
DV-RATIO) 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):
>
> Binary merge took 3
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 wrote:
> 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
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
make[1]
> -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) wrot
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
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 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
> -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 Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI) 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 latest S
> -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 [mailto:tswee...@om
On Fri, Jan 14, 2011 at 2:06 PM, KARR, DAVID (ATTSI) 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 the 1.6.15
> -Original Message-
> From: Tony Sweeney [mailto:tswee...@omnifone.com]
> Sent: Friday, January 14, 2011 10:57 AM
> To: KARR, DAVID (ATTSI); users@subversion.apache.org
> Subject: RE: SVN 1.6.15 checkout fails on particular file
>
> You can't mix Subversion client releases where the middl
You can't mix Subversion client releases where the middle digit of the
version number differs. Subversion clients are backwards compatible
when talking to the server, but not when writing workspace metadata to
the filesystem. You can, in theory, use whatever version you like on
the client side ag
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. Th
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):
Binary merge took 3.56 seconds, text merge took 3:45:45.202 hours.
In this particular case, binary merge performance
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
http://mail-archive
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 wrote:
> On Fri, Jan 14, 2011 at 02:12:56PM +0100, peter.schwei...@gmail.com wrote:
>> Hi Folks,
>>
>> i
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 tr
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 br
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 window
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
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 anothe
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 mu
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
w
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
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 br
32 matches
Mail list logo
