headers
Augie Fackler | 1 Feb 2008 01:23
Picon
Gravatar

Re: New [PATCH] Fix issue 3026: .svn and _svn silently ignored


On Jan 31, 2008, at 5:45 PM, David Glasser wrote:

> On Dec 26, 2007 6:00 PM, Augie Fackler <durin42 <at> gmail.com> wrote:
>>
>>
>> On Nov 26, 2007, at 8:18 PM, Augie Fackler wrote:
>>
>>> Hey all,
>>>
>>> Here's shot #2 at $subj. The log message is crazy long because I
>>> touched lots of files in one spot. As it stands, the only subcommand
>>> that treats "_svn" or ".svn" as an error is update because that's
>>> the only one that it seemed to me needed to be that way.
>>
>> Should I hold onto this until 1.5 branches? The only feedback I got
>> was that this should wait until after 1.5 because we were close to  
>> the
>> branch point.
>
> Heh, nobody responded to this; I guess the answer's obvious now!

Yeah, pretty much. I need to work on an updated version because it has  
lotsa conflicts right now. I'll work on that presently and submit a  
revised patch.

Augie

>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Glasser | 1 Feb 2008 01:26

Re: svn commit: r28768 - in branches/issue-2897/subversion: libsvn_client tests/cmdline

On Jan 7, 2008 7:32 AM,  <kameshj <at> tigris.org> wrote:
> Author: kameshj
> Date: Mon Jan  7 07:32:32 2008
> New Revision: 28768
>
> Log:
> On the issue-2897 branch:
>
> Handle reflective file/directory additions sensibly.
>
> * subversion/libsvn_client/merge.c
>   (merge_cmd_baton_t): Add new member 'reflective_rev_affected_paths'.
>   (get_diff_summary_func_cb, summarize_reflected_ranges): New functions.
>   (reflective_merge_file_added): Refer 'cumulative reflected merges for this
>    reflective merge' and decide whether to add this file or not.
>   (reflective_merge_dir_added): Refer 'cumulative reflected merges for this
>    reflective merge' and decide whether to add this directory or not.
>   (drive_merge_report_editor): Summarize the reflected merges of reflective
>    revision prior to merging the reflective revision.
>   (do_merge): Initialize 'merge_cmd_baton_t.reflective_rev_affected_paths'.
>
> * subversion/libsvn_client/repos_diff.c
>   (close_directory): If there is no regular prop change don't even call
>    props_changed call back.
>
> * subversion/tests/cmdline/merge_tests.py
>   (test_list): Remove XFail marker from
>    'merge_non_reflective_changes_from_reflective_rev'.
>    Add XFail marker on 'reflective_merge_on_reincarnated_target' as this
>    commit breaks it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos Alberto Costa Beppler | 1 Feb 2008 02:42
Picon
Gravatar

Re: [PATCH] Authentication for svnserve using LDAP

But this appears to be simpler to configure than SASL, specially on Windows.

2008/1/31, Eric Gillespie <epg <at> google.com>:
> "Ivlev, Eugene" <eivlev <at> esignaldev.com> writes:
>
> > Authentication for svnserve using LDAP. Information about LDAP setting
> > contains in svnserve.conf. <br>
>
> Er, isn't there a SASL LDAP module?  And if not, I think you
> should write one, not clutter svnserve up with its own
> implementation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
> For additional commands, e-mail: dev-help <at> subversion.tigris.org
>
>
Permalink | Reply | 1 comment |
headers
David Glasser | 1 Feb 2008 02:43

Re: Spurious file deletions with reintegrate merge

On Jan 30, 2008 11:57 AM, David Glasser <glasser <at> davidglasser.net> wrote:
>
> On Jan 30, 2008 11:48 AM, David Glasser <glasser <at> davidglasser.net> wrote:
> > On Jan 30, 2008 9:55 AM, David Glasser <glasser <at> davidglasser.net> wrote:
> > > On Jan 30, 2008 8:00 AM, Kamesh Jayachandran <kamesh <at> collab.net> wrote:
> > > > Hi All,
> > > >
> > > > I found one case where --reintegrate deletes a file where it should not.
> > > >
> > > > a)Create a /trunk and /trunk/tfile.txt in r1.
> > > > b)copy /trunk /fb in r2
> > > > c)Add /fb/bfile.txt in r3
> > > > d)delete /trunk/tfile.txt in r4
> > > > e)merge /trunk to /fb and commit it in r5
> > > > f)add /trunk/tfile.txt in r6
> > > > g)merge /fb $trunk_wc --reintegrate
> > > >
> > > > g) should only add 'bfile.txt'. But g) removes 'tfile.txt' and adds
> > > > 'bfile.txt'.
> > >
> > > Thanks for the catch, Kamesh.  I attached a shell script that reproduces this.
> > >
> > > It looks like it's doing a
> > >
> > > $ svn merge $URL/trunk <at> 3 $URL/branches/fb .
> > > instead of
> > > $ svn merge $URL/trunk <at> 4 $URL/branches/fb .
> >
> > Worse, it's actually choosing trunk <at> 6.  Grr, that doesn't make any sense.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Augie Fackler | 1 Feb 2008 03:09
Picon
Gravatar

Re: New [PATCH] Fix issue 3026: .svn and _svn silently ignored


On Jan 31, 2008, at 6:23 PM, Augie Fackler wrote:

>
> On Jan 31, 2008, at 5:45 PM, David Glasser wrote:
>
>> On Dec 26, 2007 6:00 PM, Augie Fackler <durin42 <at> gmail.com> wrote:
>>>
>>>
>>> On Nov 26, 2007, at 8:18 PM, Augie Fackler wrote:
>>>
>>>> Hey all,
>>>>
>>>> Here's shot #2 at $subj. The log message is crazy long because I
>>>> touched lots of files in one spot. As it stands, the only  
>>>> subcommand
>>>> that treats "_svn" or ".svn" as an error is update because that's
>>>> the only one that it seemed to me needed to be that way.
>>>
>>> Should I hold onto this until 1.5 branches? The only feedback I got
>>> was that this should wait until after 1.5 because we were close to  
>>> the
>>> branch point.
>>
>> Heh, nobody responded to this; I guess the answer's obvious now!
>
> Yeah, pretty much. I need to work on an updated version because it  
> has lotsa conflicts right now. I'll work on that presently and  
> submit a revised patch.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Phippard | 1 Feb 2008 03:18
Picon
Gravatar

Some merge bugs in 1.5 branch

I have a local copy of Subclipse repository.  Dumped and Loaded with
1.5.x branch build.

I wanted to do a simple test of merge all eligible revisions.  So I did this:

HEAD is r2383

svn cp -r 1874 url://trunk url://branches/feature-branch

I should be able to checkout the feature branch and then do this:

svn merge url://trunk

And have the revisions 1874:2382 merged to the branch.  Instead,
nothing happens.  Bug #1

svn mergeinfo displays nothing.  I think this is because there is no
svn:mergeinfo property, but it seems like it should still show stuff.
Bug #2.

I then did a --record-only merge of r1875 and committed.  svn
mergeinfo now somewhat works:

$ svn mergeinfo
Path: .
  Source path: /trunk
    Merged ranges: r1884:1885
    Eligible ranges: r1874:1884, r1885:2383

But even after this, svn merge url://trunk still does nothing.
(Continue reading)

Permalink | Reply | 4 comments |
headers
C. Michael Pilato | 1 Feb 2008 04:00
Favicon
Gravatar

Re: svn commit: r29087 - in branches/svnadmin-upgrade/subversion: include libsvn_fs libsvn_fs_base libsvn_fs_fs libsvn_repos svnadmin

David Glasser wrote:
>> +/* A callback which is called when the upgrade starts. */
>> +static svn_error_t *
>> +upgrade_started(void *baton)
>> +{
>> +  apr_pool_t *pool = (apr_pool_t *)baton;
>> +
>> +  SVN_ERR(svn_cmdline_printf(pool,
>> +                             _("Repository lock acquired.\n"
>> +                               "Please wait; upgrading the"
>> +                               " repository may take some time...\n")));
>> +  SVN_ERR(svn_cmdline_fflush(stdout));
>> +
>> +  /* Enable cancellation signal handlers. */
>> +  setup_cancellation_signals(signal_handler);
>> +
>> +  return SVN_NO_ERROR;
>> +}
> 
> I believe this callback is being called in the repos function, not the
> FS function, so when it is called it is simply not true for FSFS: the
> lock has not been acquired yet.  (Yeah, it's a pain that the BDB lock
> is acquired in repos code but not the FSFS lock...)

This code was copied wholesale from the implementation of 'svnadmin 
recover', so we'll need to fix that, too.

>> +          SVN_ERR(svn_cmdline_fflush(stdout));
>> +          SVN_ERR(svn_repos_upgrade(opt_state->repository_path, FALSE,
>> +                                    upgrade_started, pool, pool));
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Glasser | 1 Feb 2008 04:33

Re: svn commit: r29087 - in branches/svnadmin-upgrade/subversion: include libsvn_fs libsvn_fs_base libsvn_fs_fs libsvn_repos svnadmin

On Jan 31, 2008 7:00 PM, C. Michael Pilato <cmpilato <at> collab.net> wrote:
> (I find it both surprising and utterly annoying that we apparently can't
> serialize access to FSFS repositories, only FSFS filesystems inside
> repositories.  What night of drunken revelry inspired that?)

This is a feature.  Reads in FSFS require no lock-checking, ever.
Having to put the lock check at the repos layer would make that goal a
lot more difficult.

--dave

--

-- 
David Glasser | glasser <at> davidglasser.net | http://www.davidglasser.net/
Permalink | Reply | 0 comments |
headers
David Glasser | 1 Feb 2008 04:34

Re: svn commit: r29118 - trunk/subversion/libsvn_fs_fs

On Jan 31, 2008 5:42 PM,  <kfogel <at> tigris.org> wrote:
> Author: kfogel
> Date: Thu Jan 31 17:42:45 2008
> New Revision: 29118
>
> Log:
> * subversion/libsvn_fs_fs/fs_fs.c
>   (ensure_revision_exists): Doc improvements, following up to r29106.
>
>
> Modified:
>    trunk/subversion/libsvn_fs_fs/fs_fs.c
>
> Modified: trunk/subversion/libsvn_fs_fs/fs_fs.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_fs_fs/fs_fs.c?pathrev=29118&r1=29117&r2=29118
> ==============================================================================
> --- trunk/subversion/libsvn_fs_fs/fs_fs.c       (original)
> +++ trunk/subversion/libsvn_fs_fs/fs_fs.c       Thu Jan 31 17:42:45 2008
>  <at>  <at>  -1298,8 +1298,18  <at>  <at> 
>    return SVN_NO_ERROR;
>  }
>
> -/* Throw an error if the given revision is newer than the current
> -   youngest revision. */
> +/* Return SVN_ERR_FS_NO_SUCH_REVISION if the given revision is newer
> +   than the current youngest revision or is simply not a valid
> +   revision number, else return success.
> +
> +   FSFS is based around the concept that commits only take effect when
> +   the number in "current" is bumped.  Thus if there happens to be a rev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karl Fogel | 1 Feb 2008 04:35
Favicon
Gravatar

Re: svn commit: r29124 - branches/1.5.x

hwright <at> tigris.org writes:
> * STATUS: Followup to r29122, remove duplicate entries for r29098, -101,
>   and add kfogel's votes to the already-approved group.

Thanks, Hyrum, I didn't notice them down there in Approved Changes.
Note that I edited your log message to spell out r29101 in full,
because more searchable.

(If my machine weren't running tests on Augie Fackler's latest patch
for issue #3026 right now, I'd merge the above, test 1.5.x, and commit.)

-Karl

> --- branches/1.5.x/STATUS	(original)
> +++ branches/1.5.x/STATUS	Thu Jan 31 19:29:26 2008
>  <at>  <at>  -14,16 +14,6  <at>  <at> 
>  
>  Candidate changes:
>  
> - * r29101
> -     Avoid unnecessary RA reparenting operations.
> -   Votes:
> -     +1: kfogel
> -
> - * r29098
> -     Add trivial early-out check, reindenting as a result.
> -   Votes:
> -     +1 kfogel
> -
>   * r29107, r29085:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane