Ramkumar Ramachandra wrote on Tue, Jul 27, 2010 at 09:12:34 +0530:
> Daniel Shahaf writes:
> > I can't reproduce it using tr...@{yesterday}:
>
> That's because Bert fixed it in r979416 :)
Bert's fix was committed about an hour before I made my @{yesterday} remark, so
the build I was using would n
What does WC-NG stand for? Working Copy ... with only 1 .svn folder
instead of nested .svn folders at every level, is that correct?
I'll tell you the one way in which that might not completely solve
the use-case that I have in mind, and that is doing a series of
partial exports from multiple
Hi Daniel,
Daniel Shahaf writes:
> Ramkumar Ramachandra wrote on Tue, Jul 27, 2010 at 00:02:07 +0530:
> > Hi,
> >
> > It's a little late here, and I don't have the patience the debug this
> > segmentation fault right now. Here's the backtrace from a simple `svn
> > diff`: if it helps, revision-0.
Hi Bert,
rhuij...@apache.org writes:
> Author: rhuijben
> Date: Mon Jul 26 19:35:44 2010
> New Revision: 979416
>
> URL: http://svn.apache.org/viewvc?rev=979416&view=rev
> Log:
> Remove a left over reference to revert properties. New code should talk
> about base_properties or pristine_properties
In viewing the --skipfilesmatchingsize flag as an optimization rather than a
filter, perhaps one could take it a step further and incorporate this
functionality into the export command itself by default rather than as an
option so that the average svn user doesn't have to concern himself/herself
On Mon, Jul 26, 2010 at 9:59 PM, Stefan Sperling wrote:
> On Mon, Jul 26, 2010 at 05:30:56PM +0100, Bolstridge, Andrew wrote:
>> If you have a directory full of source files,
>> and it contains a sub-directory full of almost-never-changing, large
>> binary files, then it would be great to initiate
Ramkumar Ramachandra wrote on Tue, Jul 27, 2010 at 00:02:07 +0530:
> Hi,
>
> It's a little late here, and I don't have the patience the debug this
> segmentation fault right now. Here's the backtrace from a simple `svn
> diff`: if it helps, revision-0.dump had just been `svn mv`ed from
> revision0
Ramkumar Ramachandra wrote on Mon, Jul 26, 2010 at 22:17:44 +0530:
> rhuij...@apache.org writes:
> > + def diff_props(dict1, dict2, name, match):
I wrote some 'dict diffing' code a long time ago in run_and_verify_info().
Maybe it's relevant to this thread...
On Mon, Jul 26, 2010 at 05:30:56PM +0100, Bolstridge, Andrew wrote:
> If you have a directory full of source files,
> and it contains a sub-directory full of almost-never-changing, large
> binary files, then it would be great to initiate an export and have it
> recognise the binaries haven't change
[ VERY briefly, since it's middle of the night here ]
Stefan Sperling wrote on Mon, Jul 26, 2010 at 16:33:45 +0200:
> In this case though, I'd like to explicitly ask any readers who have silently
> been following the thread to voice their opinion, especially if they
> differ with my view. Maybe t
Stefan Sperling wrote on Mon, Jul 26, 2010 at 16:05:23 +0200:
> On Mon, Jul 26, 2010 at 07:07:12PM +0530, Ramkumar Ramachandra wrote:
> > [[[
> > * subversion/tests/cmdline/svntest/verify.py
> > (display_lines): Additionally print unified diff output using Python
> > difflib.unified_diff.
> > ]
Hi Stefan,
I imported and ran the copy_and_modify test from svnsync. The diff I
get clearly indicates what more needs to be done, and I think this
test is very valuable. Unfortunately, `svn diff` refuses to show me
the dumpfile itself (application/octet-stream), so here's the rest of
the diff alon
Hi,
It's a little late here, and I don't have the patience the debug this
segmentation fault right now. Here's the backtrace from a simple `svn
diff`: if it helps, revision-0.dump had just been `svn mv`ed from
revision0.dump. I think it has something to do with the file's
svn:mime-type being appli
Hi,
just wanted to let you guys know that in the coming weeks I won't be able to
get the mac buildbot back online.
It'll probably be mid-september or so, when my exams and other work is
finished.
Lieven
Hi,
artag...@apache.org writes:
> -def revision0(sbox):
> +def revision_0(sbox):
>"dump revision zero"
> - run_test(sbox, dumpfile_name = "revision0.dump")
> + run_test(sbox, dumpfile_name = "revision-0.dump")
>
> +def copy_and_modify(sbox):
> + "copy and modify"
> + run_test(sbox, "copy
Hi Julian,
Julian Foad writes:
> On Thu, 2010-07-22, Ramkumar Ramachandra wrote:
> > Jonathan Nieder writes:
> [...]
> > > > + /* Output name length, then name. */
> > > > + svn_stringbuf_appendcstr(*strbuf,
> > > > +
On Mon, Jul 26, 2010 at 12:30 PM, Bob Archer wrote:
>> 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 "svna
> 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
On Mon, Jul 26, 2010 at 10:09 AM, Ramkumar Ramachandra
wrote:
> +1
>
> I don't see how it's possible to merge, atleast at this
> stage. `svnadmin` is inherently dependent on the filesytem- we should
> be careful not to stuff too much unrelated functionality into one
> tool.
I disagree - I think w
Hi,
David Glasser writes:
> But we do. 'svn' is a wrapper around svn_client/svn_ra. 'svnadmin'
> is a wrapper around svn_repos/svn_fs. 'svn' always refers to
> repositories via URLs. 'svnadmin' always (I think) refers to
> repositories via paths. 'svnadmin' does not have a dependency on Neon
Hi Stefan,
Stefan Sperling writes:
> I am a bit worried that a loader is being worked on before the dumper is
> completely done. I think we should finish the dumper first.
Don't worry about it- I won't leave the dumper pending. It's just that
there are some changes that I'm waiting for before com
Hi Bert,
rhuij...@apache.org writes:
> Author: rhuijben
> Date: Mon Jul 26 14:24:43 2010
> New Revision: 979303
>
> URL: http://svn.apache.org/viewvc?rev=979303&view=rev
> Log:
> Add a simple property verifyer to the upgrade tests to test if the upgrade
> code correctly handles property upgrades.
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Monday, July 26, 2010 3:34 PM
> To: svnusert...@href.com
> Cc: dev@subversion.apache.org
> Subject: Re: [PATCH] new feature, lazy sync via export --
> skipfilesmatchingsize
>
[snip]
> I don't know if there is i
For people that are interested, I've recently changed the location of
the trunk nightlies. They are now hosted here:
http://people.apache.org/~hwright/svn/nightly/
The old site on orac should now redirect to people.apache.org.
-Hyrum
On Mon, Jul 26, 2010 at 8:30 AM, Justin Erenkrantz
wrote:
> On Mon, Jul 26, 2010 at 8:10 AM, Hyrum K. Wright
> wrote:
>> +1. The charter for svnadmin is currently, and should remain, solely
>> focused on local access to a repository.
>
> Why?
>
> svnadmin dump --remote
>
> seems the most intuit
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: maandag 26 juli 2010 17:15
> To: Justin Erenkrantz
> Cc: Bert Huijben; Ramkumar Ramachandra; Subversion-dev Mailing List
> Subject: Re: Proposal: Rename svnrdump
>
> On Mon, Jul 26, 2010 at 07:54:30AM -0700, Just
On Mon, Jul 26, 2010 at 8:10 AM, Hyrum K. Wright
wrote:
> +1. The charter for svnadmin is currently, and should remain, solely
> focused on local access to a repository.
Why?
svnadmin dump --remote
seems the most intuitive approach for this - as well as load, etc, etc.
We don't differentiate
On Mon, Jul 26, 2010 at 07:54:30AM -0700, Justin Erenkrantz wrote:
> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
> > (A much older suggestion was moving the code into svnsync as they are
> > related tools)
>
> I think either that or folding it into svnadmin itself. But, we don't
> need
On Mon, Jul 26, 2010 at 10:08 AM, C. Michael Pilato wrote:
> On 07/26/2010 10:54 AM, Justin Erenkrantz wrote:
>> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
>>> (A much older suggestion was moving the code into svnsync as they are
>>> related tools)
>>
>> I think either that or folding i
On 07/26/2010 10:54 AM, Justin Erenkrantz wrote:
> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
>> (A much older suggestion was moving the code into svnsync as they are
>> related tools)
>
> I think either that or folding it into svnadmin itself. But, we don't
> need another tool program
On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
> (A much older suggestion was moving the code into svnsync as they are
> related tools)
I think either that or folding it into svnadmin itself. But, we don't
need another tool program, IMO. -- justin
Kamesh Jayachandran writes:
> On 07/26/2010 07:25 PM, artag...@apache.org wrote:
>> Author: artagnon
>> Date: Mon Jul 26 13:55:25 2010
>> New Revision: 979282
>>
>> URL: http://svn.apache.org/viewvc?rev=979282&view=rev
>> Log:
>> svnrdump: Add an a no-op load editor
>>
>> * subversion/svnrdump/sv
On Mon, Jul 26, 2010 at 01:40:01PM +, svnusert...@href.com wrote:
> Hi Stefan,
>
> I do hear you. I also question whether RSync, or something, is
> truly a good option for Windows users for pulling files from a
> repository. Do you know Windows users that use RSync happily?I
> fully appr
Ann,
I am a Windows user, and I agree that such a feature shouldn't go into
the codebase. Many such features are traditionally solved using
scripting, and while scripting on unix used to be much more powerful
than on windows, this is no longer true for many years now. Instead of
creating a
On 07/26/2010 07:25 PM, artag...@apache.org wrote:
Author: artagnon
Date: Mon Jul 26 13:55:25 2010
New Revision: 979282
URL: http://svn.apache.org/viewvc?rev=979282&view=rev
Log:
svnrdump: Add an a no-op load editor
* subversion/svnrdump/svnrdump.c
(load_revisions): New function to fetch and
Hi Stefan,
I do hear you. I also question whether RSync, or something, is truly
a good option for Windows users for pulling files from a
repository. Do you know Windows users that use RSync happily?I
fully appreciate that Linux users are happy with RSync. I tried to
find the 2nd produc
On Mon, Jul 26, 2010 at 07:07:12PM +0530, Ramkumar Ramachandra wrote:
> [[[
> * subversion/tests/cmdline/svntest/verify.py
> (display_lines): Additionally print unified diff output using Python
> difflib.unified_diff.
> ]]]
+1
>
> Index: subversion/tests/cmdline/svntest/verify.py
> =
On Thu, 2010-07-22, Ramkumar Ramachandra wrote:
> Jonathan Nieder writes:
[...]
> > > + /* Output name length, then name. */
> > > + svn_stringbuf_appendcstr(*strbuf,
> > > + apr_psprintf(pool, "K %"
> > > APR_SSIZE_T_FMT "\n
Hi Stefan,
Stefan Sperling writes:
> Oh, I know that hacking time is scarce. Mine is, too.
> And I'm happy that you are very active. But please forgive me when
> I can't commit on every patch you send, or keep comments short.
Don't worry about it at all -- I totally understand. Everyone has
limit
[[[
* subversion/tests/cmdline/svntest/verify.py
(display_lines): Additionally print unified diff output using Python
difflib.unified_diff.
]]]
Index: subversion/tests/cmdline/svntest/verify.py
===
--- subversion/tests/cmdline/svn
On Mon, Jul 26, 2010 at 06:53:26PM +0530, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Sperling writes:
> > What about doing one thing at a time instead?
> >
> > I'm not trying to be sarcastic or offensive, but you seem to be trying
> > to juggle too many things at once. Writing good code
[[[
* subversion/tests/cmdline/svntest/actions.py
(run_and_verify_svnrdump): Make it more extensible by adding extra
arguments to check expected vales. Design it like
run_and_verify_svnadmin2.
* subversion/tests/cmdline/svnrdump_tests.py
(run_test, basic_svnrdump): Track the above change.
On Mon, Jul 26, 2010 at 03:16:35PM +0200, Bert Huijben wrote:
> But I'm fine with just keeping 'svnrdump' even for loading. It just uses
> 'dump' for referring that it processes dumpfiles (like svndumpfilter does),
> instead of to just dumping the repository.
+1
Stefan
Hi Stefan,
Stefan Sperling writes:
> What about doing one thing at a time instead?
>
> I'm not trying to be sarcastic or offensive, but you seem to be trying
> to juggle too many things at once. Writing good code takes time. Maybe
> if you focused more thoroughly on single tasks with a bit more p
> -Original Message-
> From: Ramkumar Ramachandra [mailto:artag...@gmail.com]
> Sent: maandag 26 juli 2010 14:13
> To: Subversion-dev Mailing List
> Subject: Proposal: Rename svnrdump
>
> Hi,
>
> I've started working on load support too, and `svnrdump load` can be
> quite misleading- shou
On Mon, Jul 26, 2010 at 05:33:20PM +0530, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Sperling writes:
> > Do all tests pass with it?
>
> Yes, they do. I ran `make check` and checked. I'm running it once
> more, just in case.
That's not neccessary. Your patch and the new diff output look
Hi,
I've started working on load support too, and `svnrdump load` can be
quite misleading- should we rename the tool? I'm floating this thread
early so that we can minimize code churn due to the rename (in tests
for example).
Thanks.
-- Ram
On Mon, Jul 26, 2010 at 05:25:10PM +0530, Ramkumar Ramachandra wrote:
> Hi Kamesh,
>
> Kamesh Jayachandran writes:
> > This breaks the 2 tests in svnrdump_tests.
> >
> >
> > Though the following inline patch may fix it you may have different plans
>
> Thanks! Yes, I'm aware that it breaks tests
On 07/26/2010 05:25 PM, Ramkumar Ramachandra wrote:
Hi Kamesh,
Kamesh Jayachandran writes:
This breaks the 2 tests in svnrdump_tests.
Though the following inline patch may fix it you may have different plans
Thanks! Yes, I'm aware that it breaks tests. Unfortunately, I have too
man
Hi Stefan,
Stefan Sperling writes:
> Do all tests pass with it?
Yes, they do. I ran `make check` and checked. I'm running it once
more, just in case.
Thanks.
-- Ram
On Mon, Jul 26, 2010 at 05:17:07PM +0530, Ramkumar Ramachandra wrote:
> Hi,
>
> Ramkumar Ramachandra writes:
> > The tests in svnsync_tests_data/ are in dumpfile v2 and these are
> > unsuitable for testing svnrdump. Hence, load all of them into a
> > repository and re-dump them in dumpfile v3 form
Hi Kamesh,
Kamesh Jayachandran writes:
> This breaks the 2 tests in svnrdump_tests.
>
>
> Though the following inline patch may fix it you may have different plans
Thanks! Yes, I'm aware that it breaks tests. Unfortunately, I have too
many uncommitted changes, and I'm still waiting for them to
On Mon, Jul 26, 2010 at 05:21:28PM +0530, Ramkumar Ramachandra wrote:
> Hi,
>
> Ramkumar Ramachandra writes:
> > Hi,
> >
> > Instead of spawning diff, I used difflib in Python. Here's the
> > result. I need a +1 to commit this since it's outside my area.
>
> Is this patch alright?
Do all tests
Hi,
Ramkumar Ramachandra writes:
> Hi,
>
> Instead of spawning diff, I used difflib in Python. Here's the
> result. I need a +1 to commit this since it's outside my area.
Is this patch alright?
Thanks.
-- Ram
Hi,
Ramkumar Ramachandra writes:
> Hi Daniel,
>
> Thanks for the review. Here's another revision.
Could someone review this patch? My subcommand patch to svnrdump
breaks all the tests and I need to fix them.
Thanks!
-- Ram
Hi,
Ramkumar Ramachandra writes:
> The tests in svnsync_tests_data/ are in dumpfile v2 and these are
> unsuitable for testing svnrdump. Hence, load all of them into a
> repository and re-dump them in dumpfile v3 format before attempting to
> add them to svnrdump_tests_data/. I still have to figure
On Mon, Jul 26, 2010 at 03:04:02AM +, svnusert...@href.com wrote:
> [[[
> Contributed Feature: enable lazy sync via new export flag,
> --skipfilesmatchingsize
> Discussed in part here: http://svn.haxx.se/users/archive-2010-07/0282.shtml
Hi Ann,
As I've said before in the discussion you've li
On Mon, Jul 26, 2010 at 01:07:14PM +0200, Stefan Sperling wrote:
> On Mon, Jul 26, 2010 at 09:59:01AM +0200, Daniel Näslund wrote:
> > Index: subversion/libsvn_client/patch.c
> > ===
> > --- subversion/libsvn_client/patch.c(rev
This breaks the 2 tests in svnrdump_tests.
Though the following inline patch may fix it you may have different plans
Index: subversion/tests/cmdline/svnrdump_tests.py
===
--- subversion/tests/cmdline/svnrdump_tests.py (revision 97
On Mon, Jul 26, 2010 at 01:04:26PM +0200, Daniel Näslund wrote:
> Hi!
>
> Posting this one here so I don't forget about it.
>
> The patch code should not change the wc when run with the --dry-run
> option but it will if we're adding a file with a parent scheduled for
> deletion.
>
> The patch co
On Mon, Jul 26, 2010 at 09:59:01AM +0200, Daniel Näslund wrote:
> [[[
> Enable the patch code to use dirs as targets if we only have property
> changes.
>
> * subversion/libsvn_client/patch.c
> (patch_target_t): Add fields 'has_text_changes' and 'has_prop_changes'
> to be able to decide if w
Hi!
Posting this one here so I don't forget about it.
The patch code should not change the wc when run with the --dry-run
option but it will if we're adding a file with a parent scheduled for
deletion.
The patch code will add a file with a parent scheduled for deletion to
the filesystem but not
Hi Ann,
Patch has not reached the list.
Did you forget attach it?
With regards
Kamesh Jayachandran
On 07/26/2010 08:34 AM, svnusert...@href.com wrote:
[[[
Contributed Feature: enable lazy sync via new export flag,
--skipfilesmatchingsize
* subversion/libsvn_client/export.c
* subversi
[[[
Contributed Feature: enable lazy sync via new export flag,
--skipfilesmatchingsize
* subversion/libsvn_client/export.c
* subversion/svn/cl.h
* subversion/svn/export-cmd.c
* subversion/svn/main.c
Summary: This feature is meant to provide an extremely easy, 80%
effective way for
A merge into a directory with a file external shows the following
problems:
1) mergeinfo at the directory is not inherited (and all files and
subdirectories get their own inheritable mergeinfo).
2) mergeinfo is added to the external file.
The mergeinfo at the external file is just wrong and u
Hi Stefan!
A few questions and a WIP patch for making the patch code deal with
property targets being dirs.
* How should we deal with SVN_ERR_ILLEGAL_TARGET? svn_wc_prop_set()
throws one of those if we for instance try to set svn:executable on a
dir or svn:ignore on a file. Should we do some
66 matches
Mail list logo
