>That would be Debian Sarge. Debian backports has svn 1.4 ... too old, I'm
>afraid.
>
>> I could try to build SVN using source, but I have my doubts.
>
>It's not inconceivable that you could build 1.6, but getting all the
>dependencies lined up could be a pain on Sarge, indeed.
>
> I'll just kee
On 15.06.2017 23:41, Peter Willis wrote:
>> Really? Version 1.1.4? Because support for file externals was added in
>> version 1.6.0, so I'm not really surprised your checkout fails. :)
>>
>> Perhaps you could consider upgrading your client?
>>
>> -- Brane
> O.K. thanks that makes sense.
> Out of d
>Really? Version 1.1.4? Because support for file externals was added in version
>1.6.0, so I'm not really surprised your checkout fails. :)
>
>Perhaps you could consider upgrading your client?
>
>-- Brane
O.K. thanks that makes sense.
Out of date package of SVN.
The failed client is on an embedd
On 15.06.2017 23:21, Peter Willis wrote:
>> Can you show the output of 'svn --version' on that computer where it doesn't
>> work? It looks like your Subversion was compiled without support for the
>> svn:// protocol (which would be really strange).
>>
>> -- Brane
> Yes, the output of that is:
>
>
>Can you show the output of 'svn --version' on that computer where it doesn't
>work? It looks like your Subversion was compiled without support for the
>svn:// protocol (which would be really strange).
>
>-- Brane
Yes, the output of that is:
svn --version
svn, version 1.1.4 (r13838)
compiled
On 15.06.2017 22:35, Peter Willis wrote:
>
> Hello,
>
>
>
> I am having an issue with an external (pointing to a file) included in
> one of my projects.
>
>
>
> I have a single external in my repository that points to a file.
>
>
>
> On my windows desktop I can check out the directory contain
Hello,
I am having an issue with an external (pointing to a file) included in one
of my projects.
I have a single external in my repository that points to a file.
On my windows desktop I can check out the directory containing the external
just fine.
The code checks out and the external
On Fri, Aug 16, 2013 at 11:14 AM, wrote:
>>>
>> In subversion's view a copy is a branch so any distinction is strictly
>> your own convention. Likewise for tags, except that there is a
>> generally accepted convention of not committing changes after a tag
>> copy. Do you have additional conven
> >
> > If a project doesn't want to accept a change, they "fork" to a new
> > "history". The tool does this with a svn cp
> > and an update to the svn:externals property. They
now
> > lose sight of what the other project commits after that fork though.
The
> > backend of where the file is sto
On Thu, Aug 15, 2013 at 6:09 PM, wrote:
>
> If a project doesn't want to accept a change, they "fork" to a new
> "history". The tool does this with a svn cp
> and an update to the svn:externals property. They now
> lose sight of what the other project commits after that fork though. The
> ba
> >> The commit won't complete you'll get an out of date error.
> >
> > That's right, isn't it. It'd be no different than two folks trying to
> > commit the same file around the same time, right (one would get an out
of
> > date error)?
>
> Right, but when working on the trunk explicitly you'd e
On Thu, Aug 15, 2013 at 5:14 PM, wrote:
>
>> > I'd actually expect it to be pretty confusing if you had multiple
>> > people committing changes based from different back-rev pegged
>> > references anywhere near the same time frame. Does your external
>> > 'notify about new versions' tool help wi
Ben Reser wrote on 08/15/2013 02:57:23 PM:
> On 8/15/13 1:05 PM, Les Mikesell wrote:
> > I'd actually expect it to be pretty confusing if you had multiple
> > people committing changes based from different back-rev pegged
> > references anywhere near the same time frame. Does your external
> >
On 8/15/13 1:05 PM, Les Mikesell wrote:
> I'd actually expect it to be pretty confusing if you had multiple
> people committing changes based from different back-rev pegged
> references anywhere near the same time frame. Does your external
> 'notify about new versions' tool help with that? Don't
On Thu, Aug 15, 2013 at 4:03 PM, wrote:
>
>>
>> I'd actually expect it to be pretty confusing if you had multiple
>> people committing changes based from different back-rev pegged
>> references anywhere near the same time frame. Does your external
>> 'notify about new versions' tool help with th
> >
> > It commits a new revision of what the file external pointed to -
pretty
> > handy. If you are pegged, it will not automagically update your
pegged
> > revision (as I'd expect), so unless you are on the HEAD or update your
peg
> > to what just committed, an update will revert your WC bac
On Thu, Aug 15, 2013 at 2:03 PM, wrote:
>
>> > We do want to modify in place. Copying back creates an additionalstep
>> > that
>
>> > is already managed quite well by SVN with externals.
>>
>> I've never done that with a file external - where does the commit go?
>
>
> It commits a new revision o
On Thu, Aug 15, 2013 at 9:03 PM, wrote:
...
> The whole discussion has centered on an attempted work around for the
> connection caching that doesn't currently occur for externals. If that can
> happen, I think we'd be very content. We're accepting of some performance
> issues. There was an XK
On Thu, Aug 15, 2013 at 2:24 PM, wrote:
>
>> >> With more complexity comes more bugs and process missteps. We're
>> >> really
>> > striving to keep things as simple as possible. We're fundamentally
>> > accepting of update times going from 2 seconds to 2 minutes. Its harder
>> > when 2 minutes
> On Thu, Aug 15, 2013 at 2:03 PM, wrote:
> >
> >> With more complexity comes more bugs and process missteps. We're
really
> > striving to keep things as simple as possible. We're fundamentally
> > accepting of update times going from 2 seconds to 2 minutes. Its
harder
> > when 2 minutes bec
On Thu, Aug 15, 2013 at 2:03 PM, wrote:
>
>> With more complexity comes more bugs and process missteps. We're really
> striving to keep things as simple as possible. We're fundamentally
> accepting of update times going from 2 seconds to 2 minutes. Its harder
> when 2 minutes becomes 20 minute
> On Thu, Aug 15, 2013 at 12:39 PM, wrote:
> >
> >> But regardless of how you identify the target
> >> file, there shouldn't be any effective difference between copying a
> >> version into your directory or using a file external as long as you
> >> don't modify it in place and commit it back - s
On Thu, Aug 15, 2013 at 12:39 PM, wrote:
>
>> But regardless of how you identify the target
>> file, there shouldn't be any effective difference between copying a
>> version into your directory or using a file external as long as you
>> don't modify it in place and commit it back - something you
> > The challenge I then see on this is one of finding all instances of
foo.c.
> > If you have foo.c copied/forked fifty times to different projects,
each of
> > which has branched a couple of times, how do you programmatically find
all
> > different instances of foo.c (to let a developer choose
On Thu, Aug 15, 2013 at 10:12 AM, wrote:
>
>> > Once you copy, you break the link. If you were to make a change to the
>> > copy, no one else would then see it.
>>
>> No one else would see it with externals either, except that you
>> wrote a custom tool to analyze the externals, see if a newer
>
> > Once you copy, you break the link. If you were to make a change to
the
> > copy, no one else would then see it.
>
> No one else would see it with externals either, except that you
> wrote a custom tool to analyze the externals, see if a newer
> revision of the original exists, and show t
On Aug 14, 2013, at 17:55, dlel...@rockwellcollins.com wrote:
>> I don't follow how each project 'sees' that fixes have been made - you
>> shouldn't see that through a pegged external.
>
> We have a tool that mimics explorer. It queries the repo for the latest
> revision on each file external (
> >
> > No HEAD revisions, all files are pegged.
> >
> > For example, if everyone is linked to a common file (foo.c, revision
20,
> > project A "pedigree") and a bug is fixed, each project will see that a
fix
> > has been made. Each project has to make a decision: to remain on the
> > current re
On Wed, Aug 14, 2013 at 5:14 PM, wrote:
>
>>
>> So the point is to intentionally pull the HEAD revision of a whole
>> bunch of files together where each is located arbitrarily and can
>> change independently? I guess that's about the opposite of the way I
>> think of version control, so I can'
Les Mikesell wrote on 08/14/2013 02:49:38 PM:
> On Wed, Aug 14, 2013 at 4:23 PM, wrote:
> >
> > Now, in our case, we do stuff for aircraft,... wouldn't it be nice to
> > maintain living pedigrees with all similar models of aircraft? Fix an
issue
> > in one place and advertise it to all the o
On Wed, Aug 14, 2013 at 4:23 PM, wrote:
>
> Now, in our case, we do stuff for aircraft,... wouldn't it be nice to
> maintain living pedigrees with all similar models of aircraft? Fix an issue
> in one place and advertise it to all the others. File externals give you
> this. It fits very well i
On 8/14/13 12:04 PM, dlel...@rockwellcollins.com wrote:
> Kevin M Radke/CedarRapids/RockwellCollins wrote on 08/14/2013 11:52:44 AM:
>> dlel...@rockwellcollins.com wrote on 08/14/2013 01:13:52 PM:
> We're ok with _some_ performance cost. Also, it might be valuable to
> the SVN community to underst
Les Mikesell wrote on 08/14/2013 01:58:29 PM:
> From: Les Mikesell
> To: dlel...@rockwellcollins.com
> Cc: kmra...@rockwellcollins.com, Ben Reser , Ivan
> Zhakov , Johan Corveleyn ,
> "users@subversion.apache.org"
> Date: 08/14/2013 01:58 PM
> Subject: Re: How
On Wed, Aug 14, 2013 at 2:04 PM, wrote:
>
>
>> Designing a build
>> management system on top of subversion using only externals
>> is risky.
>
> I disagree, but we've had this conversation already. I'd be very welcome to
> try anything to help our performance.
Externals can be very useful to as
dlel...@rockwellcollins.com wrote on 08/14/2013 01:13:52 PM:
> > I'm not sure that current SVN users accept problems with depth !=
> > infinity as much as they arrange their layout so they don't have to do
> > that. What's a common use case for needing some disjoint arrangement
> > of components
Kevin M Radke/CedarRapids/RockwellCollins wrote on 08/14/2013 11:52:44 AM:
> dlel...@rockwellcollins.com wrote on 08/14/2013 01:13:52 PM:
> > > I'm not sure that current SVN users accept problems with depth !=
> > > infinity as much as they arrange their layout so they don't have to
do
> > > tha
On Wed, Aug 14, 2013 at 1:13 PM, wrote:
>
> This is a case of trying to improve performance on externals by only
> updating externals that have changed. Without connection caching,
> performing an external update over a WAN is a test of patience. For us, our
> repo is accessed over a WAN. Its
Les Mikesell wrote on 08/14/2013 10:17:41 AM:
> From: Les Mikesell
> To: dlel...@rockwellcollins.com
> Cc: Ben Reser , Ivan Zhakov ,
> Johan Corveleyn , "users@subversion.apache.org"
>
> Date: 08/14/2013 10:18 AM
> Subject: Re: How to change paths on an externa
On Wed, Aug 14, 2013 at 11:48 AM, wrote:
>
> I believe that if we can improve external performance (speed and integration
> -- like handling externals when depth != infinity), not only would we help
> the current users of SVN that have come to accept this, but we would have a
> huge opportunity t
Ben Reser wrote on 08/11/2013 09:54:43 AM:
> From: Ben Reser
> To: Johan Corveleyn
> Cc: dlel...@rockwellcollins.com, "users@subversion.apache.org"
> , Ivan Zhakov
> Date: 08/11/2013 09:55 AM
> Subject: Re: How to change paths on an external file without a ful
On Sun, Aug 11, 2013 at 8:54 PM, Ben Reser wrote:
> On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn wrote:
>> I'm cc'ing Ben Reser (who has the above issue assigned to him) and
>> Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can
>> shed some light on the current state of "RA se
Ben Reser wrote on 08/11/2013 09:54:43 AM:
>
> On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn
wrote:
> > I'm cc'ing Ben Reser (who has the above issue assigned to him) and
> > Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can
> > shed some light on the current state of "RA s
the Berlin Hackathon,
> this was deemed too risky for 1.8, but perhaps within scope for 1.9.
>
> >
> > All that said, is there a work around to convincing SVN to recreate
the file
> > without a full fledge update?
>
> No, I'm afraid I know of no workaround.
>
>
On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn wrote:
> I'm cc'ing Ben Reser (who has the above issue assigned to him) and
> Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can
> shed some light on the current state of "RA session caching".
>
> As far as I remember from discussion
On Sun, Aug 11, 2013 at 12:42 AM, wrote:
> Hi Johan,
>
> I think you are spot on on both issues - thank you.
You're welcome :-).
> The performance issue relates to SVN externals stem, in my case, from new
> connections for each http request for externals versus keeping an open one
> for non-ext
reate the
file without a full fledge update?
Thanks,
Dan
From: Johan Corveleyn
To: dlel...@rockwellcollins.com
Cc: "users@subversion.apache.org"
Date: 08/10/2013 03:15 PM
Subject: Re: How to change paths on an external file without a full
update --depth infinity?
On Sat, Aug 10, 2013 at 1:07 AM, wrote:
> Hello everyone,
>
> In an attempt to work around the slow performance issues with externals, I'm
> trying to perform selective updates on external files without performing an
> "svn update --depth infinity".
First: what "slow performance issues with exte
Hello everyone,
In an attempt to work around the slow performance issues with externals,
I'm trying to perform selective updates on external files without
performing an "svn update --depth infinity".
If I update the path on an external for foo.c to be from /bar1/ to /bar2/,
and commit the prop
Hello Daniel,
Yes, this will work , thank you!
Best RegardsScott.Yan
From: djcbecr...@gmail.com
Date: Sat, 4 Dec 2010 11:01:46 +1000
Subject: Re: external file
To: users@subversion.apache.org
CC: scott...@live.com
On Sat, Dec 4, 2010 at 10:35 AM, Scott Yan wrote:
Hi, djcbecroft
>
Please remember to Reply All to ensure the conversation stays on the list.
Maybe. You can use branches, and then use intra-repository file externals to
avoid merging the changes across.
Cheers,
Daniel B.
> Best Regards
> Scott.Yan
>
>
>
> > CC: users@subversion.a
On Thu, Dec 2, 2010 at 5:30 AM, Scott Yan wrote:
> Below is our situation:
> There are a dozen sub-factories in our company , and we develop our ERP
> system ourselves, because there are very much diffrences between factories,
> our project became a dozen versions, which means we have a dozen
On 02/12/2010, at 20:30, Scott Yan wrote:
> Hi,
>
> At first, thanks for your great works, but our company really need
> inter-repository file-externals feature which is not supported now, so , is
> there any plan to do this?
>
> Below is our situation:
> There are a dozen sub-facto
Hi,
At first, thanks for your great works, but our company really need
inter-repository file-externals feature which is not supported now, so , is
there any plan to do this?
Below is our situation:
There are a dozen sub-factories in our company , and we develop our ERP
system oursel
53 matches
Mail list logo
