On 2009-09-11, Sebastien Douche sdou...@gmail.com 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
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 operations. That's why we
On 9/15/09 10:33 , Reinout van Rees wrote:
On 2009-09-11, Sebastien Douchesdou...@gmail.com 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.
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 SCMs
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 branch
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 managed
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 a
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 posted. We
On Thu, Sep 10, 2009 at 16:58, Martijn Faassen faas...@startifact.com 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
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
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
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theunec...@gocept.com 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
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 to
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 update
isn't
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@startifact.com 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
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theunec...@gocept.com 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
Hanno Schlichting wrote:
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@startifact.com 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
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.
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohlj...@dataflake.org 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
On Sep 9, 2009, at 15:59 , Sidnei da Silva wrote:
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohlj...@dataflake.org
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
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 with SVN
On 2009-9-9 14:54, Hanno Schlichting wrote:
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@startifact.com
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
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
paths
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 being confused
On Wed, Sep 9, 2009 at 6:40 PM, Christian Theunec...@gocept.com 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
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theunec...@gocept.com 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
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
*
-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 URL.
I
-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 Theunec...@gocept.com wrote:
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
* better merge tracking
For some interpretation of better.
My team tried pretty
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
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
-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.8
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 if there is
-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 precipitating an
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
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 message
-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
committers who
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
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
(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
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
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.
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 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
[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 the
(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
[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?
The standard subversion repository layout is by project:
proj1
/trunk
/branches
/br1
/br2
...
/tags
/tag1
/tag2
...
proj2
/trunk
/branches
/br1
48 matches
Mail list logo
