You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shlomi Fish <sh...@vipe.stud.technion.ac.il> on 2003/07/01 12:27:56 UTC
Issue 620
http://subversion.tigris.org/issues/show_bug.cgi?id=620
Now I made the test on my own and discovered this:
(after the process, in the commit directory):
shlomi:~/Download/unpack/prog/SCM/svn-test/620/test# svn st -v
0 ? ? .
1 1 shlomi A
2 2 shlomi A/B
3 3 shlomi A/B/E
4 4 shlomi A/B/E/hello.txt
5 5 shlomi A/D
6 6 shlomi A/D/newdir1
6 6 shlomi A/D/newdir1/hello.txt
7 7 shlomi A/D/newdir2
7 7 shlomi A/D/newdir2/hello.txt
1 1 shlomi h
(and in the non-commit directory):
shlomi:~/Download/unpack/prog/SCM/svn-test/620/t2# svn st -v
7 7 shlomi .
7 7 shlomi A
7 4 shlomi A/B
7 4 shlomi A/B/E
7 4 shlomi A/B/E/hello.txt
7 7 shlomi A/D
7 6 shlomi A/D/newdir1
7 6 shlomi A/D/newdir1/hello.txt
7 7 shlomi A/D/newdir2
7 7 shlomi A/D/newdir2/hello.txt
7 1 shlomi h
It seems that both have the same revision, and it is of the latest commit.
Is this the normal behaviour or did the bug get worse?
Regards,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.
Falk Fish
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> Issue 620 is about the right-hand column of revisions. And no, the
> bug didn't get worse, your test case is probably just more complex.
> Looks like you're building your set of test files and dirs in pieces
> across multiple commits (revisions 1 - 6, to be exact). The test case
> in the issue presumes the standard "greek" test tree, where all the
> files and dirs are already present in a working copy up-to-date at
> revision 1.
Hmm... I wonder if this bug wouldn't be solved by removing this little
blurb of code from libsvn_client/commit.c:
if ((item->state_flags & SVN_CLIENT_COMMIT_ITEM_ADD)
&& (item->kind == svn_node_dir)
&& (item->copyfrom_url))
recurse = TRUE;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by cm...@collab.net.
Shlomi Fish <sh...@vipe.stud.technion.ac.il> writes:
> http://subversion.tigris.org/issues/show_bug.cgi?id=620
>
> Now I made the test on my own and discovered this:
>
> (after the process, in the commit directory):
>
> shlomi:~/Download/unpack/prog/SCM/svn-test/620/test# svn st -v
> 0 ? ? .
> 1 1 shlomi A
> 2 2 shlomi A/B
> 3 3 shlomi A/B/E
> 4 4 shlomi A/B/E/hello.txt
> 5 5 shlomi A/D
> 6 6 shlomi A/D/newdir1
> 6 6 shlomi A/D/newdir1/hello.txt
> 7 7 shlomi A/D/newdir2
> 7 7 shlomi A/D/newdir2/hello.txt
> 1 1 shlomi h
>
> (and in the non-commit directory):
>
> shlomi:~/Download/unpack/prog/SCM/svn-test/620/t2# svn st -v
> 7 7 shlomi .
> 7 7 shlomi A
> 7 4 shlomi A/B
> 7 4 shlomi A/B/E
> 7 4 shlomi A/B/E/hello.txt
> 7 7 shlomi A/D
> 7 6 shlomi A/D/newdir1
> 7 6 shlomi A/D/newdir1/hello.txt
> 7 7 shlomi A/D/newdir2
> 7 7 shlomi A/D/newdir2/hello.txt
> 7 1 shlomi h
>
> It seems that both have the same revision, and it is of the latest commit.
> Is this the normal behaviour or did the bug get worse?
The left-hand column of revisions is accurate -- it reflect the
repository revision to which those files and dirs was last updated.
Issue 620 is about the right-hand column of revisions. And no, the
bug didn't get worse, your test case is probably just more complex.
Looks like you're building your set of test files and dirs in pieces
across multiple commits (revisions 1 - 6, to be exact). The test case
in the issue presumes the standard "greek" test tree, where all the
files and dirs are already present in a working copy up-to-date at
revision 1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Then perhaps we should paste this discussion into issue 620, with a
> crossref (dependency?) on the fs-schema-change issues that cmpilato is
> working on. I don't think Shlomi or anyone else should "push" any
> more on this issue until we have the new 'created path' stuff to
> complement our 'created rev' idea.
Sounds great. Care to?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> The undernodes certainly *should* have a CR of 2. And 'svn update'
> *should* be assigning CR's of 2 to those nodes as well.
>
> The problem is that because our filesystem uses the cheap-copy model,
> that causes all sorts of discrepancies between the "node created rev"
> and the "path created rev". From a user's perspective, the latter is
> the interesting one. But the former is the one that doesn't cost an
> arm and a leg to calculate, and that's the only one we (currently)
> have available.
>
> I'm working on it, I'm working on it.
Then perhaps we should paste this discussion into issue 620, with a
crossref (dependency?) on the fs-schema-change issues that cmpilato is
working on. I don't think Shlomi or anyone else should "push" any
more on this issue until we have the new 'created path' stuff to
complement our 'created rev' idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by cm...@collab.net.
kfogel@collab.net writes:
> Ben Collins-Sussman <su...@collab.net> writes:
> > cmpilato and kfogel: we had a discussion about this issue last week,
> > something deep and theoretical, and I don't remember the outcome. Can
> > you guys reiterate our current feeling about this bug? (i.e. is it a
> > real bug? why or why not?)
>
> Holy cow. I don't remember what we concluded, but on reading it now,
> I'm not sure even that the answer we proposed in the issue is a good
> one...
>
> I kind of think the undernodes *should* have a CR of 2. Why should
> the versioning filesystem's shared-storage optimization -- a mere
> implementation detail -- affect what we report about a path? Those
> files are new, they did not exist before revision 2, so they should
> have a CR of 2 I think.
>
> And the way you can tell they're not the same as the files they were
> copied from is: if you change one, the other does not change, so they
> must be different objects :-). (There's some technical term for this
> kind of identity test, but I don't remember it offhand.)
>
> The fact that our filesystem had trouble distinguishing two different
> objects when they happen to share a storage key is a bug, but one
> that's maybe fixed by cmpilato's created-path work recently?
>
> Thoughts?
The undernodes certainly *should* have a CR of 2. And 'svn update'
*should* be assigning CR's of 2 to those nodes as well.
The problem is that because our filesystem uses the cheap-copy model,
that causes all sorts of discrepancies between the "node created rev"
and the "path created rev". From a user's perspective, the latter is
the interesting one. But the former is the one that doesn't cost an
arm and a leg to calculate, and that's the only one we (currently)
have available.
I'm working on it, I'm working on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> cmpilato and kfogel: we had a discussion about this issue last week,
> something deep and theoretical, and I don't remember the outcome. Can
> you guys reiterate our current feeling about this bug? (i.e. is it a
> real bug? why or why not?)
Holy cow. I don't remember what we concluded, but on reading it now,
I'm not sure even that the answer we proposed in the issue is a good
one...
I kind of think the undernodes *should* have a CR of 2. Why should
the versioning filesystem's shared-storage optimization -- a mere
implementation detail -- affect what we report about a path? Those
files are new, they did not exist before revision 2, so they should
have a CR of 2 I think.
And the way you can tell they're not the same as the files they were
copied from is: if you change one, the other does not change, so they
must be different objects :-). (There's some technical term for this
kind of identity test, but I don't remember it offhand.)
The fact that our filesystem had trouble distinguishing two different
objects when they happen to share a storage key is a bug, but one
that's maybe fixed by cmpilato's created-path work recently?
Thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 620
Posted by Ben Collins-Sussman <su...@collab.net>.
Shlomi Fish <sh...@vipe.technion.ac.il> writes:
> http://subversion.tigris.org/issues/show_bug.cgi?id=620
Shlomi, I'm glad you're looking at issues, it's great!
But can you give a teeny-tiny bit more context when you send these
mails? Just saying "I'm working on issue N" forces everyone to go
look up the bug just to even know what you're talking about. Maybe
add a couple of sentences as well? :-)
cmpilato and kfogel: we had a discussion about this issue last week,
something deep and theoretical, and I don't remember the outcome. Can
you guys reiterate our current feeling about this bug? (i.e. is it a
real bug? why or why not?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org