You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2006/03/09 11:24:09 UTC
Why we have NULL txn_id for delta representation?
Hi,
I could see all 'delta' representations having TXN as 0. I could see the
code of subversion/libsvn_fs_base/reps-strings.c@18787:line 1544 causing
this behaviour.
Can someone clarify.
P.S I could see the mention of Representation's TXN acting as a kind of
mutablity flag. I think we clone only the 'nodes' entries for the path
getting changed not the representations, as we put the youngest as
'fulltext' so why we need to clone the corresponding representations
rather we can create new representations.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why we have NULL txn_id for delta representation?
Posted by kf...@collab.net.
Kamesh Jayachandran <ka...@collab.net> writes:
> Thanks Karl.
> Yes, understood about the 'bubble-up' stuff from the
> subversion/libsvn_fs_base/notes/structure doc.
> Will see which gets cloned whether nodes table entries or their
> representations too which I don't think
Okay, in that case:
> >> I am yet to see how/where the cloning happens.
> >> I guessed by reading the subversion/libsvn_fs_base/fs-history doc that
> >> on each change of the path all the path components are cloned and
> >> corresponding changes are done to a clone, wondered that there should
> >> be no such cloning in 'representations' and 'strings' tables as the
> >> youngest is always fulltext.
...I don't quite understand the question being asked here, but if you
can clarify it (i.e., ask it more verbosely), I'd be happy to try and
answer.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why we have NULL txn_id for delta representation?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Thanks Karl.
Yes, understood about the 'bubble-up' stuff from the
subversion/libsvn_fs_base/notes/structure doc.
Will see which gets cloned whether nodes table entries or their
representations too which I don't think
With regards
Kamesh Jayachandran
kfogel@collab.net wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
>> My current understanding of mutablity is that history(past) should not
>> be muted, not the internal representation of it, i.e representation
>> could change from 'fulltext' to 'delta' and viceversa as long as view
>> of the consumers of the representation is same before and after this
>> change.
>>
>
> This is correct, yes.
>
>
>> I am yet to see how/where the cloning happens.
>> I guessed by reading the subversion/libsvn_fs_base/fs-history doc that
>> on each change of the path all the path components are cloned and
>> corresponding changes are done to a clone, wondered that there should
>> be no such cloning in 'representations' and 'strings' tables as the
>> youngest is always fulltext.
>>
>
> Cloning happens during the process of committing a change to a path.
> Before I explain it, let me ask: do you know what the "bubble up"
> algorithm in the Subversion repository is? That is a prerequisite for
> understanding how trees and history are stored in the repository.
>
> Best,
> -Karl
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why we have NULL txn_id for delta representation?
Posted by kf...@collab.net.
Kamesh Jayachandran <ka...@collab.net> writes:
> My current understanding of mutablity is that history(past) should not
> be muted, not the internal representation of it, i.e representation
> could change from 'fulltext' to 'delta' and viceversa as long as view
> of the consumers of the representation is same before and after this
> change.
This is correct, yes.
> I am yet to see how/where the cloning happens.
> I guessed by reading the subversion/libsvn_fs_base/fs-history doc that
> on each change of the path all the path components are cloned and
> corresponding changes are done to a clone, wondered that there should
> be no such cloning in 'representations' and 'strings' tables as the
> youngest is always fulltext.
Cloning happens during the process of committing a change to a path.
Before I explain it, let me ask: do you know what the "bubble up"
algorithm in the Subversion repository is? That is a prerequisite for
understanding how trees and history are stored in the repository.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why we have NULL txn_id for delta representation?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Max,
Fine. Will it worth a mention in the subversion/libsvn_fs_base/structure
doc?
My current understanding of mutablity is that history(past) should not
be muted, not the internal representation of it, i.e representation
could change from 'fulltext' to 'delta' and viceversa as long as view of
the consumers of the representation is same before and after this change.
I am yet to see how/where the cloning happens.
I guessed by reading the subversion/libsvn_fs_base/fs-history doc that
on each change of the path all the path components are cloned and
corresponding changes are done to a clone, wondered that there should be
no such cloning in 'representations' and 'strings' tables as the
youngest is always fulltext.
Thanks.
With regards
Kamesh Jayachandran
Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kamesh Jayachandran wrote:
>
>> Hi,
>> I could see all 'delta' representations having TXN as 0. I could see the
>> code of subversion/libsvn_fs_base/reps-strings.c@18787:line 1544 causing
>> this behaviour.
>>
>> Can someone clarify.
>>
>> P.S I could see the mention of Representation's TXN acting as a kind of
>> mutablity flag.
>>
>
> Yes, that is correct.
>
> delta reps have no txn_id because they are never considered mutable.
>
>
>> I think we clone only the 'nodes' entries for the path
>> getting changed not the representations, as we put the youngest as
>> 'fulltext' so why we need to clone the corresponding representations
>> rather we can create new representations.
>>
>
> I totally don't understand that sentence.
>
> Max.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Cygwin)
>
> iD8DBQFEEBl/fFNSmcDyxYARAgyuAKDBhjaM8URrlldt6gYLXf+bnF2emACfbyvL
> WZm1l0zKnlA2FivClHhmRpU=
> =g3Z2
> -----END PGP SIGNATURE-----
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why we have NULL txn_id for delta representation?
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kamesh Jayachandran wrote:
> Hi,
> I could see all 'delta' representations having TXN as 0. I could see the
> code of subversion/libsvn_fs_base/reps-strings.c@18787:line 1544 causing
> this behaviour.
>
> Can someone clarify.
>
> P.S I could see the mention of Representation's TXN acting as a kind of
> mutablity flag.
Yes, that is correct.
delta reps have no txn_id because they are never considered mutable.
> I think we clone only the 'nodes' entries for the path
> getting changed not the representations, as we put the youngest as
> 'fulltext' so why we need to clone the corresponding representations
> rather we can create new representations.
I totally don't understand that sentence.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFEEBl/fFNSmcDyxYARAgyuAKDBhjaM8URrlldt6gYLXf+bnF2emACfbyvL
WZm1l0zKnlA2FivClHhmRpU=
=g3Z2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org