Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of tobias.strasser@gmail.com
 designates 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=aCNZokG4A0IwmvslpnRPkWB+A5hpoVSBU2X14SMFA4xwblaTxTMQUbvR76ojhI+duOXVVNHeRC7YdWDTkvg6/hR6iUCv0/iOu9ohJNEslDqh29WhHFaFBLfPNEi42dUFjv5BAl+Kwc8LBUYxRcN1gGcqszT4uApqeM+h3IpuPUQ=
Message-ID: <8be731880608080230n18357c92h9d61f7f8b97b29d5@mail.gmail.com>
Date: Tue, 8 Aug 2006 11:30:19 +0200
From: "Tobias Bocanegra" <tobias.bocanegra@day.com>
Reply-To: tobias.bocanegra@day.com
Sender: tobias.strasser@gmail.com
To: dev@jackrabbit.apache.org
Subject: Re: JSR170 for Source code Version control system
In-Reply-To: <ef62a9ce0608080132y585749a9n2d3d79caca6c3f8a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1ca10cd20608062104k80da04cn25d8d28c6759e55@mail.gmail.com>
	 <8be731880608070202u3b464b32gc1cee655a966e1c4@mail.gmail.com>
	 <ef62a9ce0608070320n24147dbfj9eeb5fbb1e733a@mail.gmail.com>
	 <fcbb46050608070353v3ae6db37g47975ea9d07c89fa@mail.gmail.com>
	 <ef62a9ce0608080132y585749a9n2d3d79caca6c3f8a@mail.gmail.com>

what you would do is to create a the 'changeset' nodes seperately, and
every version has a reference to the changeset. eg:

[Changeset] > mix:referenceable
- id (long) mandatory

[File] > nt:file, mix:versionable
- changeset (reference) < Changeset

so, when comitting, you create a new Changeset node (somewhere), udate
the reference properties to all the files, and checkin the nodes.

for restore, you get the relevant versions by
changeset.getReferences() and you can restore the nodes.

regards, toby
On 8/8/06, Piyush Purang <ppurang@gmail.com> wrote:
> Hi Nicolas,
>
> > Well you could define a property for a Global Revision Number with each
> > commit.
>
> Just having a simple global revision number will not do. We will need
> a datastructure like this
>
> grn -> versions of nodes different from last increment to grn (global
> revision number)
>
> 1 -> /a(1)
> 2 -> /a/b(1)
> 3 -> /a(2)
> 4 -> /a/b/c(1)
> 5 -> /a/b(2)
>
> so revision 5 is /a(2), /a/b(2) and /a/b/c(1)  and you can see how
> fast the GRN will be touching big numbers. We will need a mechanism of
> grouping check-ins.
>
> > Can you please elaborate on your change sets ideas: I am working on the
> > backup tool.
>
> in the cases above the changesets are the differences introduced by a
> new check-in i.e. changesets are similar to the patches you have been
> submitting for implementing the backup functionality.
>
> initial checkin -> first change set (contains all the content as we
> are starting from nothing)
> next checkin -> second change set (contains only the differences
> introduced by the new check-in)
>
> and so on..
>
> The idea then is that you back up just the changeset and not the
> entire content.
>
> Restore starts with taking the initial changeset and applying the
> changesets to the point which we need. To enhance performance one
> could maintain a structure like this
>
> changeset-init (naming isn't that important you could start with cs-0)
> changeset-2
> changeset-3
> changeset-4
> changeset-5
> mergedsets-init-5
> changeset-6
>
> so as to come to the state reperesented by changeset-6 you'd pickup
> mergedset-init-5 and apply changeset-6.  Cool would be - to arrive at
> a restore till changeset-4 you remove(subtract) changeset-5 from
> mergedsets-init-5 instead of compiling from the begining.
>
> I hope I was lucid enough. Maybe you are already doing that with your
> backup tool. I haven't followed the discussions too closely.
>
> Piyush
>
>
> On 8/7/06, Nicolas <ntoper@gmail.com> wrote:
> > Hi Piyush,
> >
> >
> > Can you please elaborate on your change sets ideas: I am working on the
> > backup tool. The first version is nearly over and I am gathering feedback
> > and comment to lay out spec for a second version.
> >
> > Nicolas
> >
> > On 8/7/06, Piyush Purang <ppurang@gmail.com> wrote:
> > >
> > > Hi Toby,
> > >
> > > Subversion uses Global Revision Numbers but Jackrabbit supports a
> > > version for each versionable item so isn't there a mismatch?
> > >
> > > What I'd really like to see is some way of building and exporting
> > > "change sets" that would make backup and restore of content easy.
> > >
> > > Cheers
> > > Piyush
> > >
> > >
> > >
> > > On 8/7/06, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
> > > > On 8/7/06, Hariharasudhan.D Dhakshinamoorthy <hariharasudhan.d@gmail.com>
> > > wrote:
> > > > > Hi !
> > > > > iam not sure if this is the right place for this , iam planning to
> > > write the
> > > > > JSR170 api for CVS , how can jackrabit help me
> > > > >
> > > > > any tips / suggestions will be appreciated
> > > > >
> > > > >
> > > > >
> > > > > thanks
> > > > > haris :-)
> > > >
> > > > i would write a webdav server for subversion that uses a jsr170 repo
> > > > for storing the data....that would be cool!
> > > >
> > > > regards, toby
> > > >
> > > >
> > > > --
> > > > -----------------------------------------< tobias.bocanegra@day.com >---
> > > > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > > > T +41 61 226 98 98, F +41 61 226 98 97
> > > > -----------------------------------------------< http://www.day.com >---
> > > >
> > >
> >
> >
> >
> > --
> > a+
> > Nico
> > my blog! http://www.deviant-abstraction.net !!
> >
> >
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---