I am migrating from Clearcase to Perforce.
Clearcase has a concept of "Recommended Baseline". Is there a similar concept in Perforce?
Also I think that the recommended baseline in clearcase is just a "Floating label". Is that correct? If so is there a floating label concept in Perforce?
The recommended baseline isn't a floating label.
It designated a label (or baseline, which won't float) used to rebase the child stream with said baseline.
You can change the recommended baseline (without triggering any rebase), but that doesn't make it "floating".
As such, it is a marker to reference to baseline which could be used to initialize or update any sub-stream.
The Perforce directory Standard (zip file with a ppt in it) is there to establish "Common elements conveyed by directory structure (non-streams) or stream model".
You find the idea of "sharable quality" labels which can then be used to initialize another stream (here "Patch").
But I didn't found any specific p4 operation which would mark that label as the one to use by default, like "recommended baseline" in ClearCase does.
(This is an example of a lifecycle phase from the PDS document, one process amongst many)
I don't think it's exactly equivalent, but Perforce promotes a mainline branching model for each product or component. In normal cases the recommended baseline would simply be the latest on the main branch. Work isn't promoted to main until it reaches a point of useful stability, while release branches isolate legacy bug fixes and customizations.
This blog post is a good starting point:
http://www.perforce.com/blog/100607/perforce-directory-standard-pds
The author is very helpful and used to be a ClearCase administrator, so you can leave some comments for him.
Related
I have found some old questions, but I doesn't really answer or clear my doubts.
Repository Pattern + Unit Of Work: it is from 2012, and they tell that really to the repository pattern is not needed nowdays. Really I would like to know if repository pattern implies always unit of work and another aspects. Anyway, it would be to know another opiniones more recents if really repository pattern is useful or not today.
DDD - the rule that Entities can't access Repositories directly: this is a good post, but it desn't talk about unit of work.
Also I have asked another questions that are not answered in this posts. So I open a new one.
I am reading some examples how to implement repository pattern, thinking in a DDD architecture.
The pattern is called repository pattern, but many of the examples that I have seen implement the both and it seems that it is a unit, it has no sense or it is not good to implement only repository pattern, that it is needed the unit of work too.
Here are some examples, that they have small difference but it is the same one to do:
https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
https://www.youtube.com/watch?v=rtXpYpZdOzM
In this examples, they use the repositories through the unit of work, so they don't use directly the repository to say in some way (really the repositories are uses because they are properties in the unit of work).
So my questions are various:
1.- When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?
2.- If it is implemented the unit of work, is it recommended to access the repositories only throuth it? Because in this examples, it is posible, in the consumer, instantiate the repositories and the unit of work. Wouldn't it be better to avoid the consumer to can use repositories and only create the unit of work?
3.- In the second link that I put, in the video, it is said that the repositories shouldn't have methods like update, that this is not the responsability of the repository, but in most cases of another examples, I always see the update method. So is it really a bad practice to have an update method in the repository? In this case, if I don't have this method and call the complete() method of the unit of work, it will work because behind the interface, the implementation uses an OR/M, but if another implementation doesn't use it, I have to notify in some way that the entity was changed. I guess an update method is the most easy to do it.
Well, in summary, I would like to know if really means to have the unit of work too or not.
Thanks.
When it is talked about pattern repository, really it means repository and unit of work or there is in some cases where it could be implemented only the repository?
From Evans, 2004
Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything.... the client presumably has the context to correctly initiate units of work.
So Evans considers them to be separable ideas.
Implicit in Evans's writing is the idea that the information of the domain model is stored in a single relational database; which means that transactions spanning multiple aggregates are fine, because the database ensures that information is persisted atomically. But when you start looking at alternatives to a monolithic SQL database, robust persistence is... tricky.
A lot of modern writing eases some of this by adding a constraint that aggregate boundaries and transaction boundaries are aligned. In this kind of a design, you might reasonably factor the transaction management into the repository facade.
As a reader, we have to be really careful that we understand the implicit constraints of the author's context.
it is said that the repositories shouldn't have methods like update, that this is not the responsibility of the repository, but in most cases of another examples, I always see the update method
Evans again:
The ideal is to hide all of the inner workings from the client (although not the developer of the client) so that the client code will be the same whether the data is stored in an object database, stored in a relational database, or simply held in memory.
There are a couple problems with this ideal
Collections simply held in memory don't have distributed failure modes like the other candidate implementations
When is the change I made visible to others is an important design consideration
So you end up with people choosing different repository interfaces depending on how/if they decide to address these issues.
The important idea to recognize here is that REPOSITORY is a pattern; something we expect to have different expressions depending on the system of forces at play.
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander, A Pattern Language (emphasis added)
I am diagramming a situation similar to Git, where you can have a single file in multiple states at once (i.e. a file with staged changes and unstaged changes). In this scenario, I have three main states:
Unedited file
Edited/unstaged file
Staged file
Is it possible to show that a single file is in both state 2 and 3 without duplicating all the state information into another state (i.e. State 4. Staged and edited/unstaged file). Here is a simplified diagram:
State machine basics
In your SM , there is no region, no composite state, nor submachines. There can therefore only be at most one state active at a given time. It's not written exactly like that, but it emerges from the semantics of the SM in the UML specs, inter alia:
A behavior StateMachine comprises one or more Regions, each Region containing a graph (possibly hierarchical) (...). A particular execution of a StateMachine is represented by a set of valid path traversals through one or more Region graphs, triggered by the dispatching of an Event occurrence (...). Due to its event-driven nature, a StateMachine execution is either in transit or in state, alternating between the two. It is in transit when an event is dispatched that matches at least one of its associated Triggers.
The graph traversal mechanism through transitions and states make it clear that two states cannot be active at the same time.
More complex state machines
State machines can be much more complex. First of all, a SM can be made of Regions:
A Region denotes a behavior fragment that may execute concurrently with its orthogonal Regions. Two or more Regions are orthogonal to each other if they are either owned by the same State or, at the topmost level, by the same StateMachine.
Furthermore composite states may have sub-states: so if this state is active, a substate of it may get active as well. And submachines may refer to even more complex situations.
In such comple SM, the curent state of the machine is in reality a configuration of several compatible active states in the hierarchy of states across the active regions.
What are your requirements?
Whenever, you feel that several states could be relevant at the same time, you must therefore decompose your states further, and identifying those who are related (e.g.: potential substates) and those who are independent (orthogonal regions).
In other words, if Unedited file, Edited/unstaged file and Staged file are not sufficient, independently of GIT semantic, you could think of:
region 1: Undedited, Edited and region 2: Staged, Unstaged, which gives 4 potential configurations: Undedited/Staged, Edited/Staged, Undedited/Unstaged, and Edited/Unstaged.
if some combinations are not possible (e.g. Undedited/Staged) youd could think of Unedited (implicitely always unstaged) and Edited as composite state with substates Staged, Unstaged, which gives the potential configurations Edited.Unstaged and Edited.Staged
Or maybe there are some missing states: e.g. new (always implicitely unstaged) committed-a-first-time, which could have 2 reagions (as in the first bullet above)
etc...
What could guide your state analysis is to find an invariant condition that best describes the state in a unique and unambiguous way.
History
SM history will not resolve your concurrent state issue:
The concept of State history (...) is a convenience concept associated with Regions of composite States whereby a Region keeps track of the state configuration it was in when it was last exited. This allows easy return to that same state configuration, if desired, the next time the Region becomes active (...), or if there is a local Transition that returns to its history.
Conclusions
The solution to your problem may be outside theSM. For instance, a file which is edited and then staged, has two versions: the current version on the local drive that is editable, and the staged unmutable version in the GIT repository. In this case you have indeed the edited staged version active and the unedited (in comparison to the staged) version. The two concurent states relate to different objects, each having its own SM.
I believe your problem stems from the fact that you are trying to model two different state machines as one.
The first is the Unedited/Edited State Machine, the second is to do with Staging. The File will be the subject of both State Machines, but the states in these machines are independent of one another: Whether the File is Staged or Un-staged is not dependent on the File having been Edited; it is dependent on whether you as a user have told Git to Stage the File or not. You can Stage a File that is Unedited, and you can choose not to Stage a File that is Edited.
The editor displaying a "E" or an "S" against the name of the File is a choice about how you want to communicate the states a File is in. I assume that a File that is not Edited, but is Staged, would have an "S" displayed by its name, regardless of the face that the File had not been Edited. Displaying these symbols is behavioural logic that is not dictated by the states, but by the interpretation of them and the possible combinations of them.
From the State diagram you have included, I'm not sure, but maybe are you trying to express the process of development in a State Machine? It would be common to Edit and then Stage, but you could do it the other way around. Have you thought about using an Activity Diagram instead to express the process?
I am working at modelling a software system using Sparx Enterprise Architect 13. This system contains different versions of software components. We typically add services and/or APIs when we release a new version of a software component.
Currently, to reflect the fact that component ServiceV1 exposes an interface A and ServiceV2 exposes interfaces A (the same as ServiceV1) and B, I make ServiceV2 extend ServiceV1. But that is not straightforward:
the generalization link is not available in diagrams between components, so I have to use Advanced > Parent...
it lacks flexibility, because I cannot override interface A with a newer version of the interface
Is there a better way to do so? What is the standard way of maintaining several versions of the same component?
Thank you!
I don't think this is standardized by some standards body, but I would recommend to introduce two levels of abstraction: the unversioned component level and the versioned component level.
On the unversioned component level, you have just a single element in the project repository for each component (not for each component version).
On the versioned component level, you have a single element in the project repository for each version of each component.
Each versioned component, e.g. MyComponentV2 has a ≪trace≫ dependency to the unversioned one, e.g. MyComponent.
To prevent unnecessary design work, you may decide to draw relationships between different components only between versioned component elements, not between unversioned component elements, or only vice versa. But this depends on the needs of your organization.
When you create a new version of a component, you copy the most recent version of the component (MyComponentV2) with all its connections, including the ≪trace≫-dependency to the unversioned component (MyComponent) and give it the right name (MyComponentV3).
I have applied this in a large project.
Actually there is no standard for modeling such a scenario. At best you can have conventions - which may differ from domain to domain. However, here's how I would model it:
ServiceV2 has a <<trace>> relation to ServiceV1. UML 2.5.1 says on p. 682:
«Trace» | Abstraction | Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.
So that should mean in this context ServiceV2 is created using ServiceV1 (I formerly used <<derive>> here since it seemed logical. But actually the UML semantic is defined differently; see p. 680 of UML 2.5.1). You could well invent your own stereotype here and explain it in the domain context (e.g. <<version of>>).
You would probably create a copy of ServiceV1 or model it manually as new element (you don't do that on a mass scenario, do you?). Here I added provided interfaces that both realize the common interface A. The quick linker does not offer those relations. You need to either go the clumsy Ctrl-I way or you grab the realization from the toolbox.
The <<derive>> dependency is not offered directly (unless you have your own MDG and defined it in QL or toolbox). So you create a dependency and choose derive from the stereotype menu.
This is a broad field and versioning is not as simple as just adding a numbering schema. In any case if you create a new component it will be something different. So the <<derive>> is probably the best option here.
EA supports this. See documentation of "Time aware models" here:
https://sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/time_aware_models.html
Allows maintaining separate versions of each package
I have a simple use case where the user can discard a profile. It is really easy to understand but raise some modeling questions.
1/ Is it okay to have a flag in my profile entity to indicate that he is in the trash ?
I don't think. So I would like to have two ProfileRepository and TrashRepository.
2/ So given those two repositories, in my application service I just have to remove the profile from his repository and add it to the trash. Seems natural but can cause troubles if I cannot have a transaction. (but it is not the case in my app).
However, I'm using a relational database and a first idea would be to use a column to indicate if the row is in the trash or not and having the two repositories working on the same table. I'm not sure that it is a good idea.
I can also add a discard method to the ProfileRepository so that I don't need the two.
Which is the best solution ?
Can I set a flag to determinate the status (discarded) in my entity or is it better to have two different entities with different repositories ?
Discard really is a business command and a command will always mutate the state of the domain. I believe that it's perfectly valid to have a status indicating that the profile has been discarded. What would be wrong is to introduce a property such as deleted or active when what you really mean is discarded.
However, some thinks that it's sometime useful to model states explicitely: have an entirely different class to represent a discarded profile.
Here's a few links related to explicit state modeling:
http://codebetter.com/gregyoung/2010/03/09/state-pattern-misuse/
http://p2p.wrox.com/book-patterns-principles-practices-domain-driven-design/94718-ch16-explicit-state-modeling-identity-map.html
https://medium.com/#martinezdelariva/explicit-state-modeling-f6e534c33508
Could please anybody interpret JCR 2.0 specification in regard to JCR workspaces ?
I understand that a session is always bound to exactly one persistent workspace, though a single persistent workspace may be bound to multiple sessions.
Which probably relates to versioning and transactions, though I don't know why.
Some observations :
references are only possible between nodes of the same workspace
executing a query will always be targeted to a single workspace
Workspaces seem to be about nodes that represent the same content (same UUID), in :
different versions of "something", project maybe ?
different phase of workflow
And shouldn't be used for ACL.
Also in JackRabbit, each workspace has its persistence manager. Whereas ModeShape has a connector for source - workspace independent.
David's model ( http://wiki.apache.org/jackrabbit/DavidsModel ) Rule #3 recommends using workspaces only if you need clone(), merge() or update(). For the vast majority of JCR applications, this means not using workspaces. Putting things under different paths, setting specific property values or mixin node types on them and using JCR's versioning covers the versioning and workflow use cases that you mention.
To manage print jobs for example, you could simply move them between JCR folders named "new", "in-progress", "rejected" and "done". That's how it is done in some unix versions, using filesystem folders. JCR allows you to do the same, while benefitting from its "filesystem on steroids" features, so as to keep things very simple, transparent and efficient.
Note also David's Rule #5: references are harmful - we (Apache Sling and Day/Adobe CQ /CRX developers) tend to just use paths instead, as looser and more flexible references.
And as you mention queries: we also use very few of those - navigation in a JCR tree is much more efficient if your content model's path structure makes sense for the most common use cases.