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
