You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2002/06/24 08:40:37 UTC
Re: svn commit: rev 2320 - branches/issue-745-dev/subversion/libsvn_fs
branches/issue-745-dev/subversion/libsvn_fs/util
cmpilato@tigris.org wrote:
>Author: cmpilato
>Date: Mon, 24 Jun 2002 03:11:54 -0500
>New Revision: 2320
>
>Modified:
> branches/issue-745-dev/subversion/libsvn_fs/fs.h
> branches/issue-745-dev/subversion/libsvn_fs/reps-strings.c
> branches/issue-745-dev/subversion/libsvn_fs/structure
> branches/issue-745-dev/subversion/libsvn_fs/util/fs_skels.c
>Log:
>Add version number to "svndiff" database storage mechanism. Idea
>gleaned from a patch by Daniel Berlin <da...@dberlin.org>. From this
>point, Daniel's implementation of svndiff v.1 (also present in the
>patch, but not of strict interest my task at hand) can be added
>without requiring a repository dump/load cycle. While this change
>*could* have been implemented to be backwards compatible, forthcoming
>changes to the filesystem code will not be, so a dump/load cycle will
>be required for all existing repositories anyway. I'm considering
>this change part of Issue #745.
>
>
Oh, coolness. I meant to do this as part of activating the delta
combiner; this is even better. :-)
It does raise a small issue, though. The delta combiner integration will
touch the same part of the code -- specifically, rep_read_range() in
reps-strings.c. In light of that, it might be best to do the combiner
change on this branch, rather than on the trunk. But that might limit
your (our) artistic freedom somewhat. :-)
Thoughts?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2320 - branches/issue-745-dev/subversion/libsvn_fs
branches/issue-745-dev/subversion/libsvn_fs/util
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
>
>
>>It does raise a small issue, though. The delta combiner integration will
>>touch the same part of the code -- specifically, rep_read_range() in
>>reps-strings.c. In light of that, it might be best to do the combiner
>>change on this branch, rather than on the trunk. But that might limit
>>your (our) artistic freedom somewhat. :-)
>>
>>Thoughts?
>>
>>
>
>Are you working off of a branch? If so, I'd say just to apply this
>same diff to your branch and then integrate away.
>
>
No, I'm still trying to figure out the best way to splice the combiner
into that code. Haven't checked in any changes yet.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2320 - branches/issue-745-dev/subversion/libsvn_fs branches/issue-745-dev/subversion/libsvn_fs/util
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> >Add version number to "svndiff" database storage mechanism. Idea
> >gleaned from a patch by Daniel Berlin <da...@dberlin.org>. From this
> >point, Daniel's implementation of svndiff v.1 (also present in the
> >patch, but not of strict interest my task at hand) can be added
> >without requiring a repository dump/load cycle. While this change
> >*could* have been implemented to be backwards compatible, forthcoming
> >changes to the filesystem code will not be, so a dump/load cycle will
> >be required for all existing repositories anyway. I'm considering
> >this change part of Issue #745.
> >
> >
> Oh, coolness. I meant to do this as part of activating the delta
> combiner; this is even better. :-)
Glad to be of service!
> It does raise a small issue, though. The delta combiner integration will
> touch the same part of the code -- specifically, rep_read_range() in
> reps-strings.c. In light of that, it might be best to do the combiner
> change on this branch, rather than on the trunk. But that might limit
> your (our) artistic freedom somewhat. :-)
>
> Thoughts?
Are you working off of a branch? If so, I'd say just to apply this
same diff to your branch and then integrate away.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org