Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Plastic SCM 4.1.10.434 External Release is out!!

Monday, May 06, 2013 Luix 0 Comments

Plastic SCM 4.1.10.434 (Bangkok) is already public!

Get the full list of changes here. Visit the Plastic SCM download page to install or upgrade your Plastic SCM client / server setup.

You also can suggest and vote new features on the Plastic SCM Forum page and tell us your opinion about Plastic SCM or use the User's Voice channel, as well.

Let's review what's new this week. Several of them are related to the command line tool, "cm.exe".


New

Merge + cloaked: Now the merge operation can be performed when there are cloaked items        involved on it even when the cloaked items have been locally deleted or changed.


Bugfixes

Checkin operation: Some checkin operation issues have been fixed:
  •         Checkin + exclusive checkout (lock) involved: When a copied item that was locally changed and locked was commited, a new revision was created skipping the lock.
  •         Checkin + local changes preference disabled: When a moved item that was locally changed was committed without considering the local change, then the local change was not detected. 


Revision specifications in the command line: The revision specification for an item inside an xlink did not work properly when there were multiple xlinks configured in the workspace.
Well, some commands help have been updated to reflect the revision specification of Plastic SCM 4.2.



Merge: When a merge operation contained a directory conflict and an  added writable xlink, the content inside the xlink was not applied and the merge did not finished.



Labelling from the command line:
  • If you tried to label outside a workspace, the command failed.
  • If the full specification of the changeset was not provided, the operation failed.
  • If some problem happened labeling in the server, a null was retrieved.
In addition to that:
  • Now, if the changeset full spec is not provided we assume the spec (repository) of the label.
  • Now, if the label full spec is not provided we assume the spec (repository) of the changeset or path.
  • If no path are provided, assume current path (workspace).
Let's see some examples:

#1
A) cm label lb:BL001
B) cm label lb:BL001@default@myserver:8084

Executed inside a workspace it will label the current workspace with the label BL001
Actually, the changeset loaded in the workspace will be labelled with BL001.

-------------------------------------------------------

#2
A) cm label lb:BL001 cs:1
B) cm label lb:BL001@default@myserver:8084 cs:1
C) cm label lb:BL001 cs:1@default@myserver:8084
D) cm label lb:BL001@default@myserver:8084 cs:1@default@myserver:8084
Executed inside a workspace it will label the changeset specified in the repository specified by the label with the label BL001.
To make it work outside a workspace you need to use option B), C) or D)

-------------------------------------------------------

#3
A) cm label lb:BL001 C:\mywkspath
B) cm label lb:BL001@default@myserver:8084 C:\mywkspath

Executed inside a workspace it will label the specified workspace with the label BL001.
To make this work outside a workspace you need to use option B)
Actually, the changeset loaded in the workspace will be labelled with BL001.

It's worth to remark that this new behaviour doesn't affect the old one, but extend it in a more user friendly way.

Enjoy!

Luix

0 comentarios:

Subscribe to: Post Comments (Atom)