jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: JSR-170 clarification - workspaces, branching, etc.
Date Mon, 30 May 2005 00:06:09 GMT
hi miro,

> > > It seems like quite a lot would depend on
> > > the efficiency of some of these operations (in particular, merge, as
> > > it would need to be called every time a branched content set needed to
> > > be viewed).
> > really? i don't really see that.
> > for example, let's say you have a release 1.0 and a
> > release 2.0 of a piece of software in your repository then i
> > would probably assume a workspace per "release".
> > in my mind the merge() would only be called if a developer
> > patches release 1.0 and would also need to apply it to release
> > 2.0 on node that already experienced a check-in for 2.0?
> > in my mind that should not happen to frequently. please
> > apologize if i misunderstood your comment...
> So, if I understand correctly, without a merge being called, any
> patches made to the 1.0 worspace copy of a class (node) that had _not_
> been checked-in in the 2.0 workspace would not appear in the 2.0
> workspace...? 
that's correct, as long as no operation such as clone, update or merge
is called.

> This is what it appears to imply, as the base version of
> the node in question would be older in the 2.0 workspace than it would
> be in the 1.0 workspace, and only after merging would the 2.0
> workspace reflect the patch made in the 1.0 workspace. If that's
> correct, then it would appear the only way to tell by looking at the
> 2.0 workspace if a patch had been applied in the 1.0 workspace would
> be by calling merge()...?
hmm... i would argue that when the patch is applied to v1.0 the patch
should be checked-in therefore versioned, which then means that 
comparing the base version should do the trick, to find out that there
is a branch.
i guess from a versioning perspective in my experience we branch 
very often (once per release) and almost never merge, and personally
i don't really care what people do as long as it is not checked-in.

if i was in charge of the development guidlines on our fictitious example 
here i would probably postulate that every change on past releases 
should probably be checked-in as quickly as possible...

does that make sense? 

> > personally, i think that the "content explorer" usually helps quite bit
> > to wrap your head around the spec.
> Content Explorer? I haven't found this - where is this? I couldn't see
> anything like this in the contrib directories... or am I being blind?


sorry, i forgot to mention that. it is our generic jsr-170 webgui... 
can be downloaded freely for development purposes or just be
used online for explanatory purposes.


View raw message