> On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
> > On 05.04.2010 17:06, Stefan Sperling wrote:
> > > An idea we're playing with to mitigate this problem is having
> designated
> > > properties in the svn: namespace which allow users to tell svn what
> their
> > > branching/merging
> In particular, there are people who have patches for svn, and we don't
> handle them very well. In some cases, there is a high bar of
> review/change/resubmit that turns people off. In other cases, people
> are focused on whatever task they're working on, and the patches are
> left by the wayside
> > P.S. Plase, introduce true tags, no more "lets pretend this copy
> is
> > a tag".
>
> I agree here - branches are great, but sometimes you want a 'snapshot'
> or a 'baseline' that doesn't require a whole new directory in the repo
> (especially as the number of branches you have increases,
> On Fri, Apr 9, 2010 at 10:13, Vadim Chekan wrote:
> > P.S. Plase, introduce true tags, no more "lets pretend this copy is
> a tag".
>
> What's a "true" tag? What's it good for? How would it behave?
I'm not Vadim but...
Basically an attribute added to a path at a certain revisions. I would
> The trick is to use the --stop-on-copy (to stop at branch point)
> -v (to show patsh) options of the svn log command:
>
> $ svn log --stop-on-copy -v .
>
> r3 | stsp | 2010-04-09 22:25:24 +0100 (Fri, 09 Apr 2010) | 1 line
>
> I think it would be nice to store more repositories in one database, but
> I find this way a bit confusing and without significant advantages (e.g.
> it would be not clear which rows belong to which repository).
Please don't do this unless it is an option. Each repository should be self
contain
> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
> that this is a bug before I submit it.
>
> Overview: For files, 'svn mv' does not properly inherit ACL
> permissions from the parent directory.
>
> Steps to reproduce (from a subversion working directory):
> 1. setfacl -d -m
> I have a repository that is partially mirrored, using svnsync and
> mod_authz_svn [1]. I just realised that the administrator of the
> mirror server can bypass the authz rules I've set up on the master
> server. All he has to do is change the svn:sync-from-url property
> on the mirror repositor
> I have repeatedly heard similar complaints and would therefore
> prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working
> copies
> starting with 1.7. And I have never heard anyone asking for the
> auto-upgrade
> feature to be kept.
>
> The CLI client can print an error. GUI clie
> >> We are only ever going to hear the complaints. That does not
> mean
> >> they speak for the majority of users.
> >
> > Oh, I didn't mean to imply that I'd expect people to write in
> > out of the blue, asking for the feature to be kept.
> >
> > I meant to say that I cannot recall any user eve
> Most users don't like doing something more and most don't use
> multiple
> clients on a single working copy which is really where the
> automation
> bites you. That said, I wouldn't argue that making this change
I agree with that. However, it isn't often that you will be upgrading from 1.x
to 1
> On Fri, Jul 2, 2010 at 07:32, Julian Foad
> wrote:
> >...
> > Now enabling it ...
> >
> > r959954: subversion/libsvn_wc/wc.h: Enable the pristine text
> store: bump
> > the WC format to 17 and define SVN_EXPERIMENTAL_PRISTINE.
>
> Awesome! Kudos to you and Philip for the heavy lifting on that!
> On 22 July 2010 03:12, dave b wrote:
> > On 22 July 2010 02:58, Bolstridge, Andrew
> > wrote:
> >>> -Original Message-
> >>> excuse to say "we told you so".
> >>
> >> Considering Windows is case-insensitive, how do you expect to be
> able to see folder FOO and foo inside folder bar? I
> On Fri, Jul 23, 2010 at 22:38, C. Michael Pilato
> wrote:
> > Over in another thread[1], a question was raised about the
> behavior of 'svn
> > switch --relocate' today. Namely, if you run 'svn switch --
> relocate' on a
> > subdirectory of a working copy (that is, *not* a "working copy
> root"
> We used to be brutal against adding flags let alone separate
> binaries,
> so why are we so willing to add new binaries willy-nilly? To me,
> as
> an admin, it just makes *so* much sense that a remote dump feature
> be
> tied into "svnadmin dump". -- justin
I agree this makes sense.
You coul
> Yes, the new 1.7 feature sounds very promising. I was wondering
> what
> WC-NG stands for but I think I get the idea.
Working Copy Next Generation
BOb
> Quiet a lot of users have reported that they would like to have a
> flag in svn update that allows them to update several sub
> directories in one command
>
> (when using sparse checkout),
>
> for example: a command like this
>
> svn up a\b\c\d will bring folder d with its content, and its
>
umed the request was to "pull in" a/b/c/d to a wc that
> doesn't
> > have it yet... in which case I have to assume the OP (Elango)
> meant '--set-depth=empty'.
> >
> > (it's not an unreasonable feature idea IMO)
> >
> > Bob Archer wr
> On 29.07.2010 16:28, Bob Archer wrote:
> >> Sorta kinda. Let's use our own tree as an example. We start
> with
> >> an empty checkout of the root of our project:
> >>
> >> $ svn co --depth empty
> http://svn.apache.org/repos/asf/subversion
&
> * Client site-wide configuration (/etc/subversion)
> * Client user-specific configuration (~/subversion, 'svn --config-
> dir')
> * Repository-dictated configuration (as described above)
> * Explicit configuration supplied by the client application
>('svn --config-option', or Eclipse conf
> On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson
> wrote:
> > On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
> >> I'm doing some more thinking about repository-dictated
> configuration,
> >
> > I get nervous when I see people talk about repository-dictated
> > configuration as an extension
> Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200:
> > On 07.08.2010 12:44, Daniel Shahaf wrote:
> >> If corporations want to have configuration override, fine.
> >>
> >> But I want a way to disable that completely. I don't
> necessarily want to
> >> allow a random sourceforge repository
> > Summary...
> >
> > There are two issues here...
> >
> > 1. The repo admin wants to enforce what is commited to their
> repo.
> This
> > exists with scripts but common request can be made inherient repo
> settings
> > (probably need to be path based).
> >
>
> The issue with pre-commit hooks is
> On 08/07/2010 12:18 PM, Greg Hudson wrote:
> > My thinking about repository configuration is that the uses cases
> > should be divided into two categories:
> >
> > 1. Stuff that isn't really client configuration at all, like
> > auto-props, should come from the repository instead, and should
>
> On 11.08.2010 11:05, Bolstridge, Andrew wrote:
> > The second aspect: client-stored passwords, this isn't so much
> about storing them on the client but about having different ones.
> Enterprises want single-signon, ie, a single password, centrally
> held, that is used for all apps. They don't re
> Back up a step. *What* data do you need to query? Maybe there is a
> more
> direct solution.
>
> I very much dislike a special mode for wc_db. It just screams
> "hack".
>
> On Aug 27, 2010 10:07 AM, "Philip Martin"
>
> wrote:
> > "Bert Huijben" writes:
> >
> >> I really think that it is much
> On Fri, Aug 27, 2010 at 05:54:38PM +0100, Julian Foad wrote:
> > The trouble is, people often won't find out until some time after
> > they've upgraded, especially if it's a WC they aren't working on
> at the
> > moment and they try to come back to work on it some weeks later.
> And
> > for most
> On Fri, Oct 15, 2010 at 4:19 PM, wrote:
> > Author: philip
> > Date: Fri Oct 15 14:19:36 2010
> > New Revision: 1022931
> >
> > URL: http://svn.apache.org/viewvc?rev=1022931&view=rev
> > Log:
> > Implement status using per-dir queries. On my machine (Linux,
> local
> > disk) this improves the
> >> - cold cache: 1.7 is almost 50% faster than 1.6
> >> 1.7: 22s
> >> 1.6: 42s
> >>
> >> - hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
> >> 1.7: 0.86s
> >> 1.6: 0.72s
> >>
> >
> > What do you guys mean by "cold cache" and "hot cache"? If they
> mean what I think they mean, woul
> So the proposed help text below centers around the most common use
> cases.
Wow... this looks great. It will be nice to have this at the command line.
I read through it all... only found one small nit:
> If several commits to trunk were related to the fix, multiple
> revisions
> to
> Suppose I have a directory tree:
>
> foo/
> bar/
> zig
>
> and I delete the tree foo/bar and replace it by a file foo/bar.
> What
> should "svn revert --depth=files foo" do? Should it revert
> foo/bar?
> How much of foo/bar should it restore?
You have done the following:
1. De
> Bob Archer writes:
>
> >> Suppose I have a directory tree:
> >>
> >> foo/
> >> bar/
> >> zig
> >>
> >> and I delete the tree foo/bar and replace it by a file foo/bar.
> >> What
> >> should
> Bob Archer writes:
>
> >> Suppose I have a directory tree:
> >>
> >> foo/
> >> bar/
> >> zig
> >>
> >> and I delete the tree foo/bar and replace it by a file foo/bar.
> >> What
> >> should
> On 02/10/2011 12:34 PM, Julian Foad wrote:
> > p.s. C-Mike, did I dream it, or did you implement something
> similar
> > just a few weeks ago? Maybe --parents for another subcommand?
>
> Wow. I mean ... just ... wow.
>
> /me cries.
Is that a yea or nay?
BOb
> "C. Michael Pilato" writes:
>
> > On 04/11/2011 05:53 AM, Philip Martin wrote:
> >> "C. Michael Pilato" writes:
> >>
> >>> But we obviously have precedent for supporting committed copies
> >>> of deeply switched things, so perhaps this isn't the best use
> of our time
> >>> right now.
> >>
> >
> C. Michael Pilato wrote on Mon, May 02, 2011 at 13:20:30 -0400:
> > On 04/27/2011 02:42 AM, Daniel Shahaf wrote:
> > > to add other keys if you want) to
> ^/subversion/site/keys/$username.asc .
> >
> > I wonder if we couldn't reduce data duplication by instead
> recommending that
> > committers u
> Fire up your testing environments: they're going to get some use
> over
> the next couple of months.
>
> In an effort to release early and often, I'd like to cut the first
> 1.7.0 pre-release on June 1. This will likely be a beta release,
> since there are still blocking issues, but I hope to g
> while working on issue #3887 I discovered an error message that
> doesn't
> sound right to me, but English is not my native language so I might
> be
> wrong:
>
> Source and destination URLs appear not to all point to the same
> repository.
Should it be:
"Source and destination URLs do not all
> On Wed, May 18, 2011 at 10:52 PM, C. Michael Pilato
> wrote:
> > On 05/18/2011 09:44 PM, Bob Archer wrote:
> >>> while working on issue #3887 I discovered an error message that
> >>> doesn't
> >>> sound right to me, but English is not
> On 05/19/2011 11:34 AM, Julian Foad wrote:
> > On Thu, 2011-05-19 at 11:26 +0200, Julian Foad wrote:
> >> A WC format bump is imminent, in order to rename the pristine
> text
> >> files from '' to '.pristine', as discussed in the
> thread
> >> 'Add ".svn-base" suffix to the pristine files in 1.7'
> I keep my personal photos and videos in Subversion.
> Total repository size is currently 475 GB. There are
> some large (1-4 GB) video files. Everything seems to
> work fine.
>
> Some details: I'm still running Subversion 1.4.6 on the
> server (FSFS, CentOS 5, x86_64). Running 1.6.16
> cmdlin
> On Mon, May 23, 2011 at 3:07 PM, Konstantin Kolinko
> wrote:
> > 2011/5/23 Mark Phippard :
> >> On Mon, May 23, 2011 at 2:24 PM, Daniel Shahaf
> wrote:
> >>> Bob Archer wrote on Mon, May 23, 2011 at 13:54:59 -0400:
> >>>> I can't imagine
> If you want to fix Subversion merge there are two issues that have
> to
> be addressed. If you are not addressing these issues you are just
> rearranging the deck chairs on the Titanic.
>
> 1. Cyclic merges (the reason we added --reintegrate).
>
> http://subversion.tigris.org/issues/show_bug.c
> On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright
> wrote:
> > On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard
> wrote:
> >> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> wrote:
> >>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard
> wrote:
>
> Finally, in your new design do not
> On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright
> wrote:
>
> > Because I'm a nice guy (and to allow people time to comment),
> I'll
> > wait until tomorrow morning to create the branch, but plan on it
> then.
>
> +1
Is that a +1 that Hyrum is a nice guy, or that he will wait, or that he shou
> Hi Everybody,
> thanks for all the quick repsonses. I myself wasn't able to answer
> until
> now since we wanted to discuss things in our group.
>
> We plan to integrate this so that a compromised server does not
> allow
> the attacker to read data, even if he has got access to the
> repositorie
> On Tue, Jul 26, 2011 at 1:48 PM, Hyrum K Wright
> wrote:
> > All,
> > 1.7.0-beta2 is out in the wild, and folks are testing it. I know
> > we're still fixing bug and STATUS is still a bit active, but how
> do
> > folks feel about starting the release candidate train? Or, if
> you're
> > uncomf
> I would like to propose to add a way to abort updates in case of an conflict.
> This could be done by adding e.g. an abort command to the interactive
> conflict resolution. This should transform the working copy to the situation
> before the update that resulted in an conflict happend.
>
> The r
> On Tue, Aug 09, 2011 at 03:55:00PM -0400, Bob Archer wrote:
> > > I would like to propose to add a way to abort updates in case of an
> conflict.
> > > This could be done by adding e.g. an abort command to the
> > > interactive conflict resolution. This should tr
> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
> >> Subversion 1.7.0
> >
> > Ok, make that a -1 to release as Subversion 1.7.0
> >
> > Subversion working copies that contain 'svn lock'-style locks can't be
> > upgraded by our
> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer
> wrote:
> >> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release
> >> >> +as
> >> >> Subversion 1.7.0
>
> Mark Phippard wrote on Fri, Sep 02, 2011 at 12:02:02 -0400:
> > On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
> > wrote:
> > > Hyrum K Wright writes:
> > >
> > >> sqlite> select * from sqlite_master where type = 'index' and
> > >> tbl_name = 'WCROOT';
> > >> index|sqlite_autoindex_WCROOT_1
> On Sat, Sep 10, 2011 at 03:43:36AM +0200, Stefan Sperling wrote:
> > It seems that the elision algorithm is very basic at the moment, which
> > prevents this from being really useful. Subversion only elides
> > mergeinfo which exactly matches the mergeinfo of a parent.
> > It doesn't perform elis
> On Thu, Oct 27, 2011 at 12:29 PM, Mark Phippard
> wrote:
> On Thu, Oct 27, 2011 at 1:16 PM, Eric S. Raymond wrote:
> I subscribed before the the mechabics of the dev list changed, nd now can't
> figure out how to unsubscribe. the page at
>
> http://subversion.apache.org/mailing-lists.html
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: Friday, October 12, 2012 3:03 PM
> To: Daniel Shahaf
> Cc: dev@subversion.apache.org
> Subject: Re: Update that pulls a null delta
>
> On 10/12/2012 10:05 AM, Daniel Shahaf wrote:
> > If an update pulls i
> On Fri, 9 Aug 2013 11:21:23 +0300
> Daniel Shahaf wrote:
>
> > > 1. Get the sources for 1.9
> > > 2. Examine svn_cl__cmd_table
> > > 3. Prepare a doc build tree that creates two things:
> > > a. man pages
> > > b. plain text for --help, one file per subcommand
> > >
> > > The pla
You should be able to update from any path. I'm not sure if they can run
"concurrently" though.
svn [PATH...]
BOb
From: Mihai Danila [mailto:virid...@gmail.com]
Sent: Wednesday, September 04, 2013 3:13 PM
To: Philip Martin
Cc: dev@subversion.apache.org
Subject: Re: SVN update of child ignores
57 matches
Mail list logo
