You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joe Swatosh <jo...@gmail.com> on 2007/09/23 22:10:51 UTC

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Hi Karl,

On 9/21/07, kfogel@tigris.org <kf...@tigris.org> wrote:
> Author: kfogel
> Date: Fri Sep 21 23:44:33 2007
> New Revision: 26745
>
> Log:
> Implement 'svn propset --depth' and 'svn propget --depth'.
>
> This is part of issue #2847 ('depthy APIs') and issue #2844 ('take
> care of "TODO(sd)" comments').
>

A Ruby binding test has been failing since this commit.  I can't reproduce via
the command line.  Last time this happened I assumed it was the bindings, but
50 commits later it was fixed.  So this time I'll try to explain.

Below is an excerpt from the failing test.  I've put my best understanding of
what the command line equivalent would be after each line of Ruby, along with
some outputlike stuff...

    ctx.ps(prop_name, prop_value, dir_path)
# svn propset prop_name prop_value wc -R
    ctx.ci(@wc_path)
# svn commit wc -m ""
    assert_equal({
                   dir_uri => prop_value,
                   uri => prop_value,
                 },
                 ctx.pg(prop_name, dir_path))
# svn propget prop_name -R wc
#wc - prop_value
#wc\sample.txt - prop_value
    ctx.up(@wc_path)
# svn update
    ctx.pdel(prop_name, dir_path, false) <== false means non-recursive
# svn propdel prop_name wc
    ctx.ci(@wc_path)
# svn commit wc -m ""
    assert_equal({uri => prop_value}, ctx.pg(prop_name, dir_path))
# svn propget prop_name -R wc
#wc\sample.txt - prop_value

The failure is that there are no properties on the file.

BTW when I was trying to reproduce this on the command line, I found this
tidbit interesting:

  D:\SVN\r26758>svn co file:///D:/SVN/r26758/repos/wc wc
  Checked out revision 1.
  D:\SVN\r26758>echo sdfkj>wc\t.txt

  D:\SVN\r26758>svn add wc\t.txt
  A         wc\t.txt

  D:\SVN\r26758>svn commit wc -m ""
  Adding         wc\t.txt
  Transmitting file data .
  Committed revision 2.

  D:\SVN\r26758>svn propset pn pv wc -R
  property 'pn' set (recursively) on 'wc'

  D:\SVN\r26758>svn commit wc -m ""
  Sending        wc
  svn: Commit failed (details follow):
  svn: Out of date: '/wc' in transaction '2-2'

  D:\SVN\r26758>svn up wc
  At revision 2.

  D:\SVN\r26758>svn commit wc -m ""
  Sending        wc
  Sending        wc\t.txt

  Committed revision 3.

I was suprised that I couldn't commit the propset until after an update.  I
always thought after committing the add of the file that the working copy
would be in sync with the repository.  The tests obviously already consider
this.

Thanks,
--
Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Joe Swatosh <jo...@gmail.com>.
On 9/25/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Joe Swatosh" <jo...@gmail.com> writes:
> > It occurred to me yesterday that these Ruby bindings failures are as a
> > result of the meaning of 'recursive' changing in a replaced api.  IOW
> > this is really a continuation of our discussion about r26607.  So is
> > this just another place where changing the behavior of an existing api
> > WRT recursion has been deemed not a regression?
>
> I think that's probably the case.  My apologies that I haven't
> confirmed that for certain yet -- just have some other things on my
> front burner (principally issues #695/#2842).
>
No worries.  I've been looking at updating the 'prop' methods to use
the latest apis (this avoiding this issue entirely), and I think I've
kicked over a big rock.

--
Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Karl Fogel <kf...@red-bean.com>.
"Joe Swatosh" <jo...@gmail.com> writes:
> It occurred to me yesterday that these Ruby bindings failures are as a
> result of the meaning of 'recursive' changing in a replaced api.  IOW
> this is really a continuation of our discussion about r26607.  So is
> this just another place where changing the behavior of an existing api
> WRT recursion has been deemed not a regression?

I think that's probably the case.  My apologies that I haven't
confirmed that for certain yet -- just have some other things on my
front burner (principally issues #695/#2842).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Joe Swatosh <jo...@gmail.com>.
Hi Karl

On 9/23/07, Joe Swatosh <jo...@gmail.com> wrote:
> On 9/23/07, Karl Fogel <kf...@red-bean.com> wrote:
> > "Joe Swatosh" <jo...@gmail.com> writes:

>

It occurred to me yesterday that these Ruby bindings failures are as a
result of the meaning of 'recursive' changing in a replaced api.  IOW
this is really a continuation of our discussion about r26607.  So is
this just another place where changing the behavior of an existing api
WRT recursion has been deemed not a regression?

--
Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Joe Swatosh <jo...@gmail.com>.
On 9/23/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Joe Swatosh" <jo...@gmail.com> writes:
> > I think I knew that.  What was surprising was that the 'svn commit wc' above
> > didn't make the 'wc' be at revision 2.  If I had done 'svn commit
> > wc\t.txt' I would
> > have expected (at least not questioned) the behavior I got.
>
> You mean this part?
>
>  D:\SVN\r26758>svn add wc\t.txt
>  A         wc\t.txt
>
>  D:\SVN\r26758>svn commit wc -m ""
>  Adding         wc\t.txt
>  Transmitting file data .
>  Committed revision 2.
>
> No, that doesn't bump 'wc' itself to r2.  Since the only change in the
> working copy is the addition of 't.txt', the commit command would have
> the same effect whether you ran
>
>   svn commit wc -m ""
>
> or
>
>   svn commit wc\t.txt -m ""
>
> In the first instance, Subversion would crawl the working copy to
> detect changes, see that t.txt has been added, see no other changes,
> and therefore commit the addition of t.txt.  In the second case,
> Subversion wouldn't crawl, it would just establish that the named
> target had been changed (which indeed it had -- it was added), and
> commit the change: again, the addition of t.txt.
>
> Neither scenario is a commit of the directory 'wc', and neither will
> increment the revision of 'wc' itself.  Try it, and take a look at
> .svn/entries afterwards to see.
>
> HTH,
> -Karl
>
That was indeed the part.  Thanks for the explanation, it helped a lot.

Any progress on the Ruby bindings portion of the question? :-)
--
Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Karl Fogel <kf...@red-bean.com>.
"Joe Swatosh" <jo...@gmail.com> writes:
> I think I knew that.  What was surprising was that the 'svn commit wc' above
> didn't make the 'wc' be at revision 2.  If I had done 'svn commit
> wc\t.txt' I would
> have expected (at least not questioned) the behavior I got.

You mean this part?

  D:\SVN\r26758>svn add wc\t.txt
  A         wc\t.txt

  D:\SVN\r26758>svn commit wc -m ""
  Adding         wc\t.txt
  Transmitting file data .
  Committed revision 2.

No, that doesn't bump 'wc' itself to r2.  Since the only change in the
working copy is the addition of 't.txt', the commit command would have
the same effect whether you ran

   svn commit wc -m ""

or

   svn commit wc\t.txt -m ""

In the first instance, Subversion would crawl the working copy to
detect changes, see that t.txt has been added, see no other changes,
and therefore commit the addition of t.txt.  In the second case,
Subversion wouldn't crawl, it would just establish that the named
target had been changed (which indeed it had -- it was added), and
commit the change: again, the addition of t.txt.

Neither scenario is a commit of the directory 'wc', and neither will
increment the revision of 'wc' itself.  Try it, and take a look at
.svn/entries afterwards to see.

HTH,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Joe Swatosh <jo...@gmail.com>.
On 9/23/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Joe Swatosh" <jo...@gmail.com> writes:
> >   D:\SVN\r26758>svn propset pn pv wc -R
> >   property 'pn' set (recursively) on 'wc'
> >
> >   D:\SVN\r26758>svn commit wc -m ""
> >   Sending        wc
> >   svn: Commit failed (details follow):
> >   svn: Out of date: '/wc' in transaction '2-2'
> >
> >   D:\SVN\r26758>svn up wc
> >   At revision 2.
> >
> >   D:\SVN\r26758>svn commit wc -m ""
> >   Sending        wc
> >   Sending        wc\t.txt
> >
> >   Committed revision 3.
> >
> > I was suprised that I couldn't commit the propset until after an update.  I
> > always thought after committing the add of the file that the working copy
> > would be in sync with the repository.  The tests obviously already consider
> > this.
>
> I haven't looked at the Ruby failures in detail yet, but I think
> what's going on above is that the "-R" is causing property "pn" to be
> set to value "pv" down through the entire working copy -- on
> directories as well as files.  Subversion requires directories to be
> completely up-to-date before you can commit property changes to them.

I think I knew that.  What was surprising was that the 'svn commit wc' above
didn't make the 'wc' be at revision 2.  If I had done 'svn commit
wc\t.txt' I would
have expected (at least not questioned) the behavior I got.

>
-----snipped additional explanation and recipe.
>

Thanks,
--
Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26745 - in trunk/subversion: include libsvn_client svn

Posted by Karl Fogel <kf...@red-bean.com>.
"Joe Swatosh" <jo...@gmail.com> writes:
>   D:\SVN\r26758>svn propset pn pv wc -R
>   property 'pn' set (recursively) on 'wc'
>
>   D:\SVN\r26758>svn commit wc -m ""
>   Sending        wc
>   svn: Commit failed (details follow):
>   svn: Out of date: '/wc' in transaction '2-2'
>
>   D:\SVN\r26758>svn up wc
>   At revision 2.
>
>   D:\SVN\r26758>svn commit wc -m ""
>   Sending        wc
>   Sending        wc\t.txt
>
>   Committed revision 3.
>
> I was suprised that I couldn't commit the propset until after an update.  I
> always thought after committing the add of the file that the working copy
> would be in sync with the repository.  The tests obviously already consider
> this.

I haven't looked at the Ruby failures in detail yet, but I think
what's going on above is that the "-R" is causing property "pn" to be
set to value "pv" down through the entire working copy -- on
directories as well as files.  Subversion requires directories to be
completely up-to-date before you can commit property changes to them.

IOW, if you have a directory at r1 in your working copy (even though
some files/subdirs under it might be at higher revisions), then you
shouldn't be able to commit a property change to that directory until
you update it to the latest revision (even though you could commit
property changes to files or subdirs within it).

This restriction applies even if the property in question hasn't
changed (or never existed) between the working copy directory's
current revision and the latest revision in the repository.

Below is a shell script demonstrating this; it produces the following
output:

   subversion/libsvn_client/commit.c:914: (apr_err=160028)
   svn: Commit failed (details follow):
   subversion/libsvn_repos/commit.c:124: (apr_err=160028)
   svn: Out of date: '' in transaction '2-2'

---------------------------------------------------------------------------
#!/bin/sh

SVNDIR=/home/kfogel/src/subversion

SVN=${SVNDIR}/subversion/svn/svn
SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos

rm -rf repos wc import-me

${SVNADMIN} create repos
mkdir import-me
echo "This is a file." > import-me/f
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
${SVN} co -q ${URL}/ wc

cd wc
echo "a change to f" > f
${SVN} ci -q -m "changing f"
${SVN} propset -q pv pv .
${SVN} ci -q -m "try to commit propchange top level directory"
cd ..

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org