jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conoly, Brett" <Brett.Con...@digitalinsight.com>
Subject RE: Version.getPredecessors()?
Date Tue, 08 Apr 2008 15:46:56 GMT
Ok, that's actually what I was doing so I'll keep it that way, thanks a
lot to you both, it helped a lot.
Brett

-----Original Message-----
From: ppiegaze@day.com [mailto:ppiegaze@day.com] On Behalf Of Peeter
Piegaze
Sent: Tuesday, April 08, 2008 11:44 AM
To: users@jackrabbit.apache.org
Subject: Re: Version.getPredecessors()?

On Tue, Apr 8, 2008 at 11:38 AM, Conoly, Brett
<Brett.Conoly@digitalinsight.com> wrote:
> Cool, that helps a lot, thanks for the quick and detailed response.
>  One question I did have though, in the api for
>  VersionHistory.getAllVersions() it actually says that they will not
>  necessarily be in order, is this referring to the branching you were
>  talking about?
Yes, that's right. But even with a linear history you can't absolutely
count on things being in order (not sure about jackrabbit) either so
if you want to write JCR portable code the best thing to do is to
manually traverse the predecessors, as Marcel suggests

> We do have the simplest case btw, and the version
>  history should always be linear.
>  Brett
>
>
>
>  -----Original Message-----
>  From: ppiegaze@day.com [mailto:ppiegaze@day.com] On Behalf Of Peeter
>  Piegaze
>  Sent: Tuesday, April 08, 2008 11:24 AM
>  To: users@jackrabbit.apache.org
>  Subject: Re: Version.getPredecessors()?
>
>  Hi Brett,
>
>  What you want to do is:
>
>  VersionHistory h = n.getVersionHistory();
>  VersionIterator i = h.getAllVersions();
>  // iterate over all the Versions
>
>  The method Version.getPredecessors() only returns the *immediate*
>  predecessors of a given version. It is pluralized to allow for the
>  case where a single version has more than one predecessor, i.e., a
>  merge within the version graph. In the simplest case (and apparently
>  your case) each version only has one immediate predecessor.
>
>  Similarly, the method Version.getBaseVersion() returns the most
recent
>  version in the simplest case of a linear version history. In general
>  the base version, however, may not be literally the most recently
>  created version. For example, if you initally have a version graph:
>
>  v1 -> v2 -> v3*
>
>  v3 is the most recent AND the base version
>
>  if you restore v2 to the workspace, it becomes the base version
>
>  v1 -> v2* -> v3
>
>  at this point v3 is still the most recent version but v2 is the base
>  version.
>
>  The reason for doing this is that if you now make a change to the ws
>  node and check it in it will create a successor to v2, thus creating
a
>  branch:
>
>  v1 -> v2 -> v3
>            |---> v4*
>
>  At this point base and most recent again coincide in v4.
>
>  However, as  said, all this branching and merging may not apply to
>  your case, but that's the reason for the naming of these entities.
>
>  Hope this helps,
>
>  Peeter Piegaze
>
>  On Tue, Apr 8, 2008 at 10:46 AM, Conoly, Brett
>  <Brett.Conoly@digitalinsight.com> wrote:
>  > I'm currently trying to retrieve a list of all the previous
versions
>  of
>  >  a node.
>  >  I'm actually using:
>  >
>  >  <pre>
>  >  Version version = node.getBaseVersion();
>  >  Version[] versionArray = version.getPredecessors();
>  >  for (int i = 0; i < versionArray.length; i++)
>  >        versions.add(versionArray[i]);
>  >  </pre>
>  >
>  >  Going through the debugger this doesn't seem to be throwing any
>  errors
>  >  but for some reason this ALWAYS seems to return 1 version no
matter
>  how
>  >  many there actually are.
>  >
>  >  Am I doing something wrong? I'm also assuming that the BaseVersion
is
>  >  the most recent version, is this right?
>  >  Thanks,
>  >  Brett
>  >
>

Mime
View raw message