From users-return-17473-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Sun May 8 22:55:49 2011
Return-Path:
X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 8AEB33EA3
for ; Sun, 8 May 2011 22:55:49 +0000 (UTC)
Received: (qmail 57022 invoked by uid 500); 8 May 2011 22:55:49 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 56992 invoked by uid 500); 8 May 2011 22:55:48 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 56984 invoked by uid 99); 8 May 2011 22:55:48 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 May 2011 22:55:48 +0000
X-ASF-Spam-Status: No, hits=0.6 required=5.0
tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,URI_HEX
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of justinedelson@gmail.com designates 209.85.218.42 as permitted sender)
Received: from [209.85.218.42] (HELO mail-yi0-f42.google.com) (209.85.218.42)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 May 2011 22:55:44 +0000
Received: by yib12 with SMTP id 12so3037077yib.1
for ; Sun, 08 May 2011 15:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
bh=4KvuvHtbl+B+IuDE8hoHwTj7ddZnGg1e3j/Nt1fd3nI=;
b=WY0un5bRGuUSf1dUqyJX7ImkP8Kc3gY6EKS+VNlzq1yXlsLv4OfXQiv9SLAupQ+VOE
wxcEd1z72QosdDTdbsxk7B8sGrwD/o6dUC3x9uTmTjWyISRtvDxBIT/D8LLzfqKxlBDg
y0OD2PNI/mHZH9veKuyo5JbeRC0dwrmwHxf5g=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
b=GKp7GRKVHmiJDq5l4HgjjErIAIrZY+MLlkpk9JjUXgWmlxEJzQ5CBSepyzWyflNwxE
bA0h0YhBGA2GRWW13HmQ7Y2QxIsBF87XQ5ft9UJ6mbx56AnnNB/nJaQOj35U7fl8tMRl
OFRl2TgowX0ZTwkxpZEFq3Pz1BCPqFyPDvkeA=
MIME-Version: 1.0
Received: by 10.236.66.75 with SMTP id g51mr6446423yhd.524.1304895321900; Sun,
08 May 2011 15:55:21 -0700 (PDT)
Sender: justinedelson@gmail.com
Received: by 10.236.102.169 with HTTP; Sun, 8 May 2011 15:55:21 -0700 (PDT)
In-Reply-To:
References:
Date: Sun, 8 May 2011 18:55:21 -0400
X-Google-Sender-Auth: meF5wBMnedmBoBm0lI8sRCtWY7g
Message-ID:
Subject: Re: New to JCR (again) and mildly baffled by workspaces
From: Justin Edelson
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sun, May 8, 2011 at 12:32 PM, Tom Anderson wrote:
> Hello!
>
> I'm new to JCR (still - i looked into JCR, and was on this list briefly, =
a
> year ago, but never managed to make time to really understand things), an=
d
> trying to get my head around some of the concepts - in particular,
> workspaces and versioning. I have some general, non-Jackrabbit-specific,
> questions about JCR - is this a suitable place to ask them?
>
> In a post on this list several years ago:
>
> http://jackrabbit.510166.n4.nabble.com/JCR-workspace-usage-td510218.html
>
> Marcel Reutegger wrote:
>
> =A0you can look at workspaces as local checkouts of a revision control
> =A0system.
>
> That's a really useful metaphor, because i understand revision control
> systems. However, i don't understand how the parts map on to JCR. The
> workspace corresponds to a local working copy, right? So what's the
> equivalent of the central repository? What are the equivalents of updatin=
g
> and committing? How about branching and merging?
>
I think you're taking the metaphor a bit too literally. It might be
easier to think of workspaces as branches. You'd designate a single
workspace (probably "default") as the "trunk" workspace. In this
context, Node.update() could handle both "commit" and "update"
operations; Workspace.createWorkspace(name, srcWorkspace) is the
"branch" operation and VersionManager.merge() is the "merge"
operation.
> I see from the javadoc that there are methods checkin, checkout, and merg=
e -
> but that these are (as of JCR 2.0) on the VersionManager. That suggests t=
o
> me that if i'm going to use them, i'm also going to be getting involved w=
ith
> versions. Is that the case? Are workspaces and versioning inextricably
> linked? Can i use workspaces without versioning? Can i use versioning
> without workspaces?
checkin/checkout have nothing to do with workspaces. If you're going
to be using workspaces as branches, then yes, you'll need to use
versioning at some level (especially for merge operations). You can
use workspaces without versioning. You can use versioning without
workspaces.
>
> The job i'd like to use JCR for is something fairly simple. It would be
> management of an e-commerce product catalog - categories, products, SKUs,
> supporting media and so on. There would be a small merchandising team
> editing this data. The model i have is that the repository holds the mast=
er
> version of this information; when the team wants to do some work (adding =
a
> new category of products, say), they would create a new working copy of i=
t,
> do their editing, over the course of days or weeks, and when it was ready=
,
> fold it back into the master copy. There could be several such bits of wo=
rk
> in progress at once. Should i be thinking in terms of having a workspace =
for
> the master copy, and a workspace for each bit of work? A workspace for ea=
ch
> bit of work with no master workspace? A single workspace, active in multi=
ple
> sessions, using versioning to separate bits of work? Some combination of =
the
> above?
I'd tend to think of this as a single workspaces on multiple
repository instances and using an external "publish" process to move
content updates from the content development instance to the content
display instance, but you could likely do this on a single instance
with multiple workspaces.
HTH,
Justin
>
> Has anything entry-level been written about how to use workspaces and/or
> versioning? The spec is pretty opaque, and the javadocs, being javadocs,
> don't really have a single coherent narrative.
>
> Thanks in advance for any insights!
>
> tom
>
> --
> Many CS algorithms become less useful when questions start getting
> answered with "maybe". -- Eric Sink
>