jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Gash" <Simon.G...@gossinteractive.com>
Subject RE: JSR-170 clarification - workspaces, branching, etc. - Bayesian Filter detected spam
Date Thu, 02 Jun 2005 08:23:41 GMT
The jsr170tools.day.com link is broken its reporting a 500 server error.

Simon

-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com] 
Sent: 30 May 2005 01:06
To: jackrabbit-dev@incubator.apache.org; Miro Walker
Subject: Re: JSR-170 clarification - workspaces, branching, etc. -
Bayesian Filter detected spam

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?

http://jsr170tools.day.com/crx/index.jsp

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.

regards,
david

Come visit us at:
 
Internet World 2005. June 14 - 16, Earls Court, Stand # A60

Government Computing Expo. June 21 & 22, Earls Court, Stand # 804

SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28
GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte
Technology Fast 500 EMEA. 

This email contains proprietary information, some or all of which may be legally privileged.
It is for the intended recipient only. If an addressing or transmission error has misdirected
this email, please notify the author by replying to this email. If you are not the intended
recipient you may not use, disclose, distribute, copy, print or rely on this email. 

 

Email transmission cannot be guaranteed to be secure or error free, as information may be
intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This
email and any files attached to it have been checked with virus detection software before
transmission. You should nonetheless carry out your own virus check before opening any attachment.
GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software
viruses.
 


Mime
View raw message