On Tue, Sep 15, 2009 at 07:56:42AM -0400, Gary Poster wrote:
> Generally, I'd be surprised to learn that Bzr/Launchpad were alone in
> supporting this, but they are the only ones I can vouch for. For
> instance, I'm almost positive that github also allows you to have
> multiple committers to
On Sep 15, 2009, at 7:59 AM, Wichert Akkerman wrote:
> On 9/15/09 13:56 , Gary Poster wrote:
>>
>
>> 2) Our current arrangement, as well as many others, can be
>> accomplished
>> with a DVCS. Launchpad + Bzr definitely support this. You would
>> have a
>> Launchpad team of committers, with ma
On 9/15/09 13:56 , Gary Poster wrote:
>
> On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote:
>>
>> In my experience distributed SCMs add bottlenecks to development that we
>> currently do not have in the Zope community: with both our shared svn
>> repository and distributed SCMs everyone can bran
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote:
>
> In my experience distributed SCMs add bottlenecks to development
> that we
> currently do not have in the Zope community: with both our shared svn
> repository and distributed SCMs everyone can branch everything, but
> with
> distributed
Andreas Jung wrote:
> Although it is possible to use hg/bzr/svn in parallel within a project
> and a buildout, I am completely against having a mixture of SVN+HG
> or SVN+BZR within a Plone project (where Zope stuff is coming from
> BZR or HG) and the Plone stuff from SVN..if we want/need to switch
On 9/15/09 10:33 , Reinout van Rees wrote:
> On 2009-09-11, Sebastien Douche wrote:
>>
>> Caution with the actual workflow, 2 differences between SVN and Hg :
>> - you cannot check out partial repository
>> - external does not exist
>
> Missing externals has been a pain point for me.
>
> There are
On 14.09.09 20:02, Gary Poster wrote:
> On Sep 11, 2009, at 9:34 AM, Chris Withers wrote:
>
>
>> Martijn Faassen wrote:
>>
>>> Christian Theune wrote:
>>> [snip]
>>>
Same here. We also ended up in many deadlock situations having to
sacrifice chickens for SVN to resume opera
On 2009-09-11, Sebastien Douche wrote:
>
> Caution with the actual workflow, 2 differences between SVN and Hg :
> - you cannot check out partial repository
> - external does not exist
Missing externals has been a pain point for me.
There are however buildout recipes that can pull in "externals"
On Sep 11, 2009, at 9:34 AM, Chris Withers wrote:
> Martijn Faassen wrote:
>> Christian Theune wrote:
>> [snip]
>>> Same here. We also ended up in many deadlock situations having to
>>> sacrifice chickens for SVN to resume operations. That's why we
>>> started
>>> investigating alternatives whi
On Thu, Sep 10, 2009 at 16:58, Martijn Faassen wrote:
Hi Martjin
> Hey,
>
> Christian Theune wrote:
> [snip]
>> Same here. We also ended up in many deadlock situations having to
>> sacrifice chickens for SVN to resume operations. That's why we started
>> investigating alternatives which are bette
Martijn Faassen wrote:
> Christian Theune wrote:
> [snip]
>> Same here. We also ended up in many deadlock situations having to
>> sacrifice chickens for SVN to resume operations. That's why we started
>> investigating alternatives which are better at branching and merging.
>
> Please keep up poste
Hey,
Christian Theune wrote:
[snip]
> Same here. We also ended up in many deadlock situations having to
> sacrifice chickens for SVN to resume operations. That's why we started
> investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/09/2009 07:12 PM, Benji York wrote:
> On Wed, Sep 9, 2009 at 12:40 PM, Christian Theune wrote:
>> On 09/09/2009 05:05 PM, Martijn Faassen wrote:
>>> * better merge tracking
>>
>> For some interpretation of "better".
>
> My team tried pretty hard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
robert rottermann wrote:
> Martijn Faassen schrieb:
>> Hi there,
>>
>> Christian Theune wrote:
>>> a long-standing issue with our mirror of svn.zope.org are the absolute
>>> URLs of externals: they require the repository to be available on a
>>> given
What about upgrading server to 1.6.
Subversion 1.6 has many new features.
>From http://subversion.tigris.org/svn_1.6_releasenotes.html :
* Improved handling of authentication data
* Repository root relative URLs
* Improvements to svn:externals
* Detection of tree conflicts
* Fi
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theune wrote:
> On 09/09/2009 05:05 PM, Martijn Faassen wrote:
>> * better merge tracking
>
> For some interpretation of "better".
My team tried pretty hard to use 1.5's merge tracking and we could never
get it to work well for us.
The only advantage we
On Wed, Sep 9, 2009 at 6:40 PM, Christian Theune wrote:
> On 09/09/2009 05:05 PM, Martijn Faassen wrote:
>> Okay, no objection to upgrading the server to 1.5 now.
>
> That has been done a good while ago already (I was probably ambiguous in
> my mail).
Damn, Jens is just doing too much of an awesom
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
> Jens Vagelpohl wrote:
>>
>> On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
>>
>>> Ah, I perhaps misunderstood. I figured the resolving of relative
>>> externals would be a problem with a Subversion 1.4.x client.
>>
>> There's two different issues
On Sep 9, 2009, at 17:05 , Martijn Faassen wrote:
> Jens Vagelpohl wrote:
>> SVN 1.4 clients will work with SVN 1.5 repositories in general.
>> However,
>> that's not the real issue here. The issue is the new-style externals
>> definitions that allow you to use "relative" paths. Those relative
On 2009-9-9 14:54, Hanno Schlichting wrote:
> On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen
> wrote:
>> Christian Theune wrote:
>>> However, this requires Subversion 1.5 which we are using on the server
>>> already, but I don't know whether we assume clients are 1.5 or higher.
>>
>> I certainly
Jens Vagelpohl wrote:
>
> On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
>
>> Ah, I perhaps misunderstood. I figured the resolving of relative
>> externals would be a problem with a Subversion 1.4.x client.
>
> There's two different issues being confused here.
>
> SVN 1.4 clients will work w
On Sep 9, 2009, at 15:59 , Sidnei da Silva wrote:
> On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohl
> wrote:
>> SVN 1.4 clients will work with SVN 1.5 repositories in general.
>> However,
>> that's not the real issue here. The issue is the new-style externals
>> definitions that allow you to
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohl wrote:
> SVN 1.4 clients will work with SVN 1.5 repositories in general. However,
> that's not the real issue here. The issue is the new-style externals
> definitions that allow you to use "relative" paths. Those relative paths
> will not work for SVN
On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
Ah, I perhaps misunderstood. I figured the resolving of relative
externals would be a problem with a Subversion 1.4.x client.
There's two different issues being confused here.
SVN 1.4 clients will work with SVN 1.5 repositories in general.
Hanno Schlichting wrote:
> On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen wrote:
>> Christian Theune wrote:
>>> However, this requires Subversion 1.5 which we are using on the server
>>> already, but I don't know whether we assume clients are 1.5 or higher.
>> I certainly still use a SVN 1.4.x cli
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theune wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> a long-standing issue with our mirror of svn.zope.org are the absolute
> URLs of externals: they require the repository to be available on a
> given URL.
>
> I propose to use relati
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen wrote:
> Christian Theune wrote:
>> However, this requires Subversion 1.5 which we are using on the server
>> already, but I don't know whether we assume clients are 1.5 or higher.
>
> I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS
Martijn Faassen schrieb:
> Hi there,
>
> Christian Theune wrote:
>> a long-standing issue with our mirror of svn.zope.org are the absolute
>> URLs of externals: they require the repository to be available on a
>> given URL.
>>
>> I propose to use relative URLs for externals. I guess a complete upd
Hi there,
Christian Theune wrote:
> a long-standing issue with our mirror of svn.zope.org are the absolute
> URLs of externals: they require the repository to be available on a
> given URL.
>
> I propose to use relative URLs for externals. I guess a complete update
> isn't necessary, but I'd like
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theune wrote:
> As a side effect this will also make svn/svn+ssh work in a nicer way
> (IMHO) as the externals will follow the protocol of what you used for
> checkout.
I like that externals to svn:... are read-only, though I don't know
offhand whether we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
a long-standing issue with our mirror of svn.zope.org are the absolute
URLs of externals: they require the repository to be available on a
given URL.
I propose to use relative URLs for externals. I guess a complete update
isn't necessary, but I'd
Given the current level of consensus, I plan on precluding pre-1.5
Subversion clients from making commits some time after the middle of
May 2009.
I'll try add some form of warning for affected users in the next
month or so. If I can't get it to work I still plan to go forward
with the deprecation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sidnei da Silva wrote:
> On Thu, Nov 13, 2008 at 2:28 PM, Tres Seaver <[EMAIL PROTECTED]> wrote:
>> +0, I guess: I would be more comfortable if we could measure the
>> incidence of pre-1.5 client usage over time, and maybe even identify the
>> committ
On Thu, Nov 13, 2008 at 2:28 PM, Tres Seaver <[EMAIL PROTECTED]> wrote:
> +0, I guess: I would be more comfortable if we could measure the
> incidence of pre-1.5 client usage over time, and maybe even identify the
> committers who are using them, so that we can sent out a targeted
> warning messag
On 13.11.2008 14:42 Uhr, Benji York wrote:
I'd like for us to disallow pre-1.5 Subversion clients from making
commits starting one year from now (or sooner if there is consensus).
+1 - six months should be enough for the transition.
Andreas
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benji York wrote:
> I'd like for us to disallow pre-1.5 Subversion clients from making
> commits starting one year from now (or sooner if there is consensus).
>
> The recent hardware problems for svn.zope.org had the positive outcome
> of precipitatin
On Thu, Nov 13, 2008 at 1:09 PM, Jens Vagelpohl <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Nov 13, 2008, at 14:42 , Benji York wrote:
>
>> I'd like for us to disallow pre-1.5 Subversion clients from making
>> commits starting one year from now (or sooner i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 13, 2008, at 14:42 , Benji York wrote:
> I'd like for us to disallow pre-1.5 Subversion clients from making
> commits starting one year from now (or sooner if there is consensus).
+1
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.
I'd like for us to disallow pre-1.5 Subversion clients from making
commits starting one year from now (or sooner if there is consensus).
The recent hardware problems for svn.zope.org had the positive outcome
of precipitating an upgrade to Subversion 1.5 which has merge tracking.
One of the require
I plan to update our subversion server to version 1.4 this weekend.
I'll take our repositories offline for a little while while I do
this. I don't know exactly when I will do this. Hopefully, it will
happen so fast that no one will notice. :)
Jim
--
Jim Fulton ma
(cc'ing this to zope-dev in case this is of interest to them too)
Robin Becker wrote:
Chris Withers wrote:
Tim Peters wrote:
.
Cool :-)
Glad to find this one is a non-issue!
Chris
I hacked cvs2svn.py and seem to be getting it to look up the b tag in
place of the mime-types stuff which
Lennart Regebro wrote:
Well... Non-issue it is not. But it makes it much less of an issue. It
would still be nice to have server-side configurations of defalts, though.
Yeah, but from what Jim said, that's something the svn guys are aiming to do.
I guess the best thing would be to hassle/help on
Chris Withers wrote:
Tim Peters wrote:
svn's story is much better (perfect, in fact) when forgetting to add
eol-style: regardless of which kind of platform did the commit, the
property can be added after the fact by anyone, and svn will
automatically
repair working copies on all platforms. Beca
Tim Peters wrote:
svn's story is much better (perfect, in fact) when forgetting to add
eol-style: regardless of which kind of platform did the commit, the
property can be added after the fact by anyone, and svn will automatically
repair working copies on all platforms. Because (most) svn propert
[Chris Withers]
> ...
> Is it worth asking on the SVN lists how hard this would be to
> implement? I mean, we have the svn:ignore property, and we have the
> svn:eol-style property, what we want is a combination of those two,
> how hard can it be? <0.5 wink>
I don't think we want a combination of
Chris Withers wrote:
> I suppose it's still one step up from CVS where you have to specify
> the binary-ness of each file you upload rather than being able to
> put a mapping i na config file...
CVSROOT/cvswrappers
___
Zope-Dev maillist - [EMAIL PROTE
Hi Tim,
Tim Peters wrote:
There's a svn property you can set on a higher level folder in the
repository that can control a mapping for file extensions to this
property, IIRC. I am hazy on it but I know it's possible.
If so, it's not documented. Perhaps you're thinking of the svn:ignore
property?
[Chris Withers]
> ...
> There's a svn property you can set on a higher level folder in the
> repository that can control a mapping for file extensions to this
> property, IIRC. I am hazy on it but I know it's possible.
If so, it's not documented. Perhaps you're thinking of the svn:ignore
property
(cross-posted to zope-dev too, seems relevent there ;-)
Marius Gedminas wrote:
BTW the Zope subversion conversion hit a snag due to line ending style
on Windows. Apparently cvs2svn does not add the required svn:eol-style
properties for text files,
cvs2svn is a python script, surely you guys can
The standard subversion repository layout is by project:
proj1
/trunk
/branches
/br1
/br2
...
/tags
/tag1
/tag2
...
proj2
/trunk
/branches
/br1
50 matches
Mail list logo
