Beginner Dimensions CM users often do not realize that copying files and folders from one CM product/stream to another brings along 'invisible' .dm metadata files with the contents, which results in making users
1.)copy their content to the side
2.)deleting their local CM Work Area
3.)doing a GET(of the files from dimensions)
4.) then pasting in files that a .dm metadata-free.
I propose that instead of giving the user this message:
" File was locally added and conflicts with a new repository file of the same name"
and forcing them to go through the 4 painful steps above,
let's have dimensions
a.)state what CM product: project/stream the 'offending' files came from
b.)give the user an extra prompt asking if it is ok to proceed with adding the 'offending' files,
which means that files with the same names will overwrite the files in dimensions.
To be clear, the file that dimensions has trouble with have the exact same file names; it's just that the .dm metadata was inadvertently copied from somewhere else.
The Dimensions CM KB site says to use the 'merge' option to resolve conflicts of this sort between streams.
What if the user doesn't know stream all the data came from and/or doesn't want to merge all the data from one stream to another?
With that notion, it seems to me the user is forced into a 'dimensions knows best' mentality here in that files can't be copied and pasted where the user pleases.
I don't like the idea that Dimensions CM seems to get 'confused' with file metadata so easily.
And I'm the one that has to be the bearer of bad news to users to tell them all the extra work they need to do to fix these metadata issues. I, for one, cannot find a justifying reason... which makes the product look bad to users.
The metadata should be saving the user time, not taking up more time.
Many of the folks putting files into dimensions do not have developer backgrounds and computer sense enough to show hidden system files in order to delete the .dm metadata files before copying and pasting content into a dimensions project/stream.
I'll add that even seasoned developers get tripped up on this whole .dm metadata and not being able to simply copy and paste files where they need them.
As far as I am aware, Dimensions CM has hash values it keeps for each file in its repository.
With regards to implementation details of making Dimensions CM become more intelligent with .dm metadata folders/files, utilizing those hash values to see if files on the client machine truly changed could be an alternative to marking files as 'conflict' when they are the exact same file on both the local machine and dimensions repository.
If checking hash values proves to be too computationally expensive, perhaps a checkbox for "Perform Conflict Checks" could be added so that when users get 'conflicts' they know are bogus, the extra checkbox could help dimensions resolve them intelligently.
Or, maybe the hash check isn't that expensive and should become part of the dimensions UPDATE or DELIVER process.