You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Francois Beausoleil <fb...@users.sourceforge.net> on 2003/08/26 01:43:26 UTC
Recipe for non recursive commit bug
Hello everyone,
Would someone try the following recipe and tell me if it works for them ?
I reported a problem with non-recursive commits a few days ago
(http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=43681), but
cmpilato pointed out to me that I was using the wrong folder.
Today, I got the same problem, but this time, I had the right folder.
So, I wrote a reproduction recipe. If someone else can confirm the
problem, I will post a new issue.
Thanks !
François Beausoleil
Reproduction recipe
-------------------
svnadmin create repos
svn co file:///repos wc
cd wc
mkdir dirA\dirB
echo >dirA/dirB/fileA "fileA's content"
svn add dirA
svn commit -m "Adding files"
echo >dirA/dirB/fileA "fileA's modified content"
echo >dirA/fileB "fileB's content"
svn add dirA/fileB
svn st
svn commit --non-recursive -m "Does not work" dirA
svn commit -m "Works, but is recursive" dirA
Here are the results on my machine (Win2K SP4 fr_CA):
H:\>svn --version
svn, version 0.27.0 (r6715)
compiled Aug 20 2003, 02:19:40
H:\>svnadmin create repos
H:\>svn co file:///repos wc
Checked out revision 0.
H:\>cd wc
H:\wc>mkdir dirA\dirB
H:\wc>echo "fileA's content" 1>dirA/dirB/fileA
H:\wc>svn add dirA
A dirA
A dirA\dirB
A dirA\dirB\fileA
H:\wc>svn commit -m "Adding files"
Adding dirA
Adding dirA\dirB
Adding dirA\dirB\fileA
Transmitting file data .
Committed revision 1.
H:\wc>echo "fileA's modified content" 1>dirA/dirB/fileA
H:\wc>echo "fileB's content" 1>dirA/fileB
H:\wc>svn add dirA/fileB
A dirA\fileB
H:\wc>svn st
M dirA\dirB\fileA
A dirA\fileB
H:\wc>svn commit --non-recursive -m "Does not work" dirA
H:\wc>svn commit -m "Works, but is recursive" dirA
Sending dirA\dirB\fileA
Adding dirA\fileB
Transmitting file data ..
Committed revision 2.
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by cm...@collab.net.
"Francois Beausoleil" <fb...@users.sourceforge.net> writes:
> Ok, in that case, should an issue be filed for the future ?
It already has been. Something about supporting --depth in the
future.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Ok, in that case, should an issue be filed for the future ?
I will point to this thread and explain summarize things.
This would be a P5, post-1.0 issue.
Thanks !
François
On 25 Aug 2003 21:48:31 -0500, cmpilato@collab.net said:
> "Francois Beausoleil" <fb...@users.sourceforge.net> writes:
>
> > Ok, I understand your explanations.
> >
> > But, as an SVN user, wouldn't "non-recursive" mean something like "commit
> > whatever is at this depth, and nothing else beyond" ?
>
> The terms "recursive" and "non-recursive" in subversion always refer
> to a depth. In nearly all Subversion operations, "recursive" means
> a depth of infinity, and "non-recursive" means a depth of 1. However,
> 'svn commit' differs from this description in that it assign a depth
> of 0 to "non-recursive".
>
> This inconsistency is not desired behavior -- it's just that getting
> "non-recursive" to mean depth 1 for commits is a major, major hassle
> (that's been attempted at least twice to my knowledge, both times
> aborted after many many hours of failed attempts). And, it likely
> turns out not to be the most important time-sink in which to spend our
> days. :-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by cm...@collab.net.
"Francois Beausoleil" <fb...@users.sourceforge.net> writes:
> Ok, I understand your explanations.
>
> But, as an SVN user, wouldn't "non-recursive" mean something like "commit
> whatever is at this depth, and nothing else beyond" ?
The terms "recursive" and "non-recursive" in subversion always refer
to a depth. In nearly all Subversion operations, "recursive" means
a depth of infinity, and "non-recursive" means a depth of 1. However,
'svn commit' differs from this description in that it assign a depth
of 0 to "non-recursive".
This inconsistency is not desired behavior -- it's just that getting
"non-recursive" to mean depth 1 for commits is a major, major hassle
(that's been attempted at least twice to my knowledge, both times
aborted after many many hours of failed attempts). And, it likely
turns out not to be the most important time-sink in which to spend our
days. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by Jack Repenning <jr...@collab.net>.
At 10:41 PM -0400 8/25/03, Francois Beausoleil wrote:
>In our case, I would like to commit the dirA, which contains a
>modification to fileB. Had I also set a property on dirA, I would have
>expected the commit to send the propchange *and* fileB. Strictly
>speaking as a user here ;)
Well "a modification to fileB" is, it seems to me, clearly one level
deeper than "a property on dirA". It's not contained in dirA, it's
contained in dirB (which is contained in dirA). They oughtn't ever
to show up in the same non-recursive commit. A commit that includes
"the changes to the things in dirA, but no deeper" is a "one-level
recursive commit." Not to say it's not useful, just that it's a
different thing. This much of the conversation has been had before,
I think; at its heart, isn't it inspired by the fact that CVS does
this? But CVS doesn't entirely believe in directories (you have to
add them, but you never commit their adds or changes); it's a false
analogy.
But in SVN, the creation of fileB (in dirA) is an event on dirA as
well as on fileB (in any given revision, dirA does or does not
contain fileB, quite irrespective of what contents fileB may or may
not have). I would expect a non-recursive commit of dirA to include
the new propval on dirA, and the fact that there's now a fileB within
dirA, but not the new contents of dirB (zero-length file, I suppose,
or empty directory for the case where you've added a subdirectory).
I think that makes sense. Doesn't it? I think I'm arguing from
first principals and "say what's true." I don't think my judgement's
being swayed by the fact that that's how ClearCase handles this....
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Ok, I understand your explanations.
But, as an SVN user, wouldn't "non-recursive" mean something like "commit
whatever is at this depth, and nothing else beyond" ?
In our case, I would like to commit the dirA, which contains a
modification to fileB. Had I also set a property on dirA, I would have
expected the commit to send the propchange *and* fileB. Strictly
speaking as a user here ;)
I'll leave the discussion running a bit more and let a consensus arrive
before we add an issue.
Thanks !
François
On Mon, 25 Aug 2003 19:14:41 -0700, "Jack Repenning"
<jr...@collab.net> said:
> At 9:43 PM -0400 8/25/03, Francois Beausoleil wrote:
> >Hello everyone,
> >
> >Would someone try the following recipe and tell me if it works for them ?
>
> I get the same results as you.
[snip]
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Recipe for non recursive commit bug
Posted by Jack Repenning <jr...@collab.net>.
At 9:43 PM -0400 8/25/03, Francois Beausoleil wrote:
>Hello everyone,
>
>Would someone try the following recipe and tell me if it works for them ?
I get the same results as you.
However, note this one change in your script and my results for it:
At 9:43 PM -0400 8/25/03, Francois Beausoleil wrote:
>Reproduction recipe
>-------------------
>svnadmin create repos
>svn co file:///repos wc
>cd wc
>mkdir dirA\dirB
>echo >dirA/dirB/fileA "fileA's content"
>svn add dirA
>svn commit -m "Adding files"
>echo >dirA/dirB/fileA "fileA's modified content"
>echo >dirA/fileB "fileB's content"
>svn add dirA/fileB
>svn st
>svn commit --non-recursive -m "Does not work" dirA
At this point, if I "svn commit --non-recursive -mwhatever
dirA/fileB", then I get the one commit we're expecting, and the
resulting state is what we want:
> > svn commit --non-recursive -m 'does not work' dirA/fileA
>Adding dirA/fileB
>Transmitting file data .
>Committed revision 2.
>
> > svn st
>M dirA/dirB/fileA
In other words, committing the added file works, but committing the
modified directory does not.
It seems to me that "svn add dirA/fileB" constitutes a change both to
dirA and to dirA/fileB. From what you say, I think you feel the
same. But in general the SVN UI seems to disagree with us, treating
the add solely as an operation on the added object. I don't know
whether this is an actual bug or simply an incomplete projection of
the actual model (just 'cause I don't like it doesn't mean it's
wrong. I guess. ;-) But now that you draw my attention to the
matter, I think SVN is thoroughly consistent about this, for whatever
that's worth. For example, if you add a file and then "svn status,"
you don't see a line of status for the directory, only the line for
the file itself.
In contrast, note this:
> > svn propset whatever 13 dirA
>property `whatever' set on 'dirA'
>
> > svn ci --non-recursive -mx dirA
>Sending dirA
>
>Committed revision 3.
That is, a propset on the directory is versioned as if it were the
directory itself that was changed, and this --non-recursive works
(still haven't committed my change to dirA/dirB/fileA).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org