Merge contents in same workarea

Hello,

I was wondering if we could merge the two files with in same workarea. As of now i could not find any TS way to do it except unix bdiff command that i can use it in my custom script.

Thanks,
Aks
TS6.7.2-Solaris10

Find more posts tagged with

Comments

nipper

Nope, Merge happens from different branches or workareas.

When you try to merge two different files, you do not have a common ancestor which makes the merge much more difficult.

aks21

Thanks nipper.....but my requirment is the same....i have to check which files are already submitted but waiting to be deployed(deployment#1) , let say abc.dcr and later-on if same file is modified,abc.dcr, submited again and deployed immidiately(deployment#2).

how i will synchronize the content of deployment#1 with #2 when deployment#1 will be happening?

I hope i am clear...plz let me know if anybody have any doubt.

Regards,
Aks

Adam Stoller

Thanks nipper.....but my requirment is the same....i have to check which files are already submitted but waiting to be deployed(deployment#1) , let say abc.dcr and later-on if same file is modified,abc.dcr, submited again and deployed immidiately(deployment#2).

how i will synchronize the content of deployment#1 with #2 when deployment#1 will be happening?

I hope i am clear...plz let me know if anybody have any doubt.

Regards,
Aks

I don't know about nipper - but this is a lot LESS clear to me.
You started off talking about merging two files in the same workarea, now you're talking about deployments.

Deployments (OpenDeploy) overwrite files on the target system with files on the source system (assuming various other aspects not mentioned here) - there is absolutely no "merge" involved.

Merging is the result of comparing two files with each other and [usually] a common ancestor, so that one can pick-and-choose (either manually or programmatically) which differences from each of the two files should end up in the final result.

In normal TS usage - merges only occur when you have multiple workareas on the same branch; where file "foo" has been modified (N+) in both workareas and need to be merged using a common ancestor version (N).

There are utilities (like Beyond Compare) which will allow you to compare arbitrary files in either different or the same directory - and as a result of the comparison, perform a manual merging - but it's not clear from your description [now] whether that's what you're talking about needing.

aks21

@Ghoti:
My Requirments :-

1)Today, from workarea A I schedule a file a.dcr for deployment let say for tomorrow with modification , 11 of Jan. so status of this deployment is "waiting deployment".

2) Today again from workarea A, I remove/add something in a.dcr and schedule it for today 10 of jan.

Question :-

How i will make sure that a.dcr, that is going to deploy on 11 of jan, has the contents of the same file which is deployed in 10 of jan as well? thats why i asked of merging files in one workarea.

Regards,
Aks

nipper

You are thinking of this completely wrong

Here is what will happen

User A changes DCR-1 on Saturday for a Monday Deployment.

Assuming the file is unlocked and you deploy from Staging after a submit has taken place (presumably on Saturday):

User C changes DCR-1 which INCLUDES the changes from User-1 on Sunday and schedules a deployment for Thursday. The file is submitted again to Staging.

Monday the deployment takes the file from Staging (including User-B's changes) and pushes those out

May or may not be what you had planned.

If you use Editions and deploy from them, you can solve that issue (and possibly create other ones).

aks21

Thats right nipper........

1)what if the user A changes the DCR-1 and schedule it on sunday(17Jan)...

2) At same day user A (Thursday-14Jan) completely removes the earlier changes and add a new set of changes and schedule it for urgent deployment and he wants 17Jan deployment will have its own changes and also add 14 Jan changes as well.

At this point i have a two editions let say "Ed_dep_{date17}_{timestamp}" and "Ed_dep_{date14}_{timestamp}" and yes i am deploying the files from editions.

Regards,
Aks

You are thinking of this completely wrong

Here is what will happen

User A changes DCR-1 on Saturday for a Monday Deployment.

Assuming the file is unlocked and you deploy from Staging after a submit has taken place (presumably on Saturday):

User C changes DCR-1 which INCLUDES the changes from User-1 on Sunday and schedules a deployment for Thursday. The file is submitted again to Staging.

Monday the deployment takes the file from Staging (including User-B's changes) and pushes those out

May or may not be what you had planned.

If you use Editions and deploy from them, you can solve that issue (and possibly create other ones).

nipper

I expect you are building something that will ultimately be discarded. It will be overly complicated and error prone.

Write up some use cases for standard content deployment. When items are locked, when they are writable etc (for delayed deployments). Then write up some emergency deployment use cases, using the previous use cases as a baseline for content.

When you have those complete and everybody UNDERSTANDS the consequences of the design, you can build the procedures.

You may end up with a release branch and a content branch. You may end up with 2 different workflows (or more). You may end up with a number of different setups, depending on what is right for your group.