Browse Prior Art Database

Method and system to avoid file change overwritten in production environment

IP.com Disclosure Number: IPCOM000235971D
Publication Date: 2014-Apr-01
Document File: 7 page(s) / 98K

Publishing Venue

The IP.com Prior Art Database

Abstract

Customer often do some customization on software product, when customer install patch from software vendor, it's easy to overwrite the change made by customer's customzation. In this disclosure, it provides an solution to detect if the file in patch contains all changes in the files on customer's production environment, or not, if not contains all changes, then provide a list to ask customer to backup.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 7

Method and system to avoid file change overwritten in production environment

When customer install an software product, they often require software vendor to provide some specific functions according to their specific requirement (here called private patch), or they often do some change on product files directly by themselves (here called customer's customization ), also software vendor often publish some patch to fix software bug for all customer (here called common patch), different common patch may change same files, and may change same files with private patch or customer's customization. Customer often install common patch provided by software vender to fix product bug, but they don't know the detail info for the patch, i.e which files will be updated in this patch, so it's easy to overwrite the file changes in customer's customization and private patch, or common patch in some case.

Here is diagram to state version history for HelloWorld.jsp file.

1



Page 02 of 7

See below 3 cases, they are often occurred on customer production environment.

Case 1:

a: private patch#1, only publish to one customer at 2013/01/01.

files change in private patch

test.ear\test.war\HelloWorld.jsp

when build private patch#1, helloword.jsp is based on version

version#
##10

10

2



Page 03 of 7

b: common patch#2, publish to customer at 2013/02/02.

files change in common patch,

test.ear\test.war\HelloWorld.jsp

test.ear\test.war\WEB-INF\lib\test.jar.

when build patch, Helloword.jsp is based on version

version# ##99

customer first install patch#1, then install patch#2, customer don't know the detail files changes in patch#1, #2, so after install patch#2, the change in version#10 in patch#1 was overwritten by version#9.

Case 2:

a: customer's customzation#1, customer did it at 2013/01/01.

files changes in customization.

test.ear\test.war\HelloWorld.jsp

when do customization#1, helloword.jsp is based on version

version#
##888,,, generate a new version version

generate a new version version#

#8

88+++customization

customization

b: common patch#2, publish to customer at 2013/02/02.

files change in common patch#2.

test.ear\test.war\HelloWorld.jsp

test.ear\test.war\WEB-INF\lib\test.jar.

when build patch#2, helloword.jsp is based on version

version#

##99

Customer first do customization#1, then install patch#2, customer don't know the files change in patch#2, after install, the customization change in HelloWorld.jsp in customer's customization#1 was overwritten.

Case 3:

a: common path#1 to fix bug#1, publish to customer at 2013/01/01.

files changes in patch#1.

test.ear\test.war\HelloWorld.jsp

test.ear\test.war\Test.jsp

when build patch#1, helloword.jsp is based on version

version#

##22

b: common patch#2 to fix bug#2, publish to customer at 2013/02/02.

files change in common patch#2.

test.ear\test.war\HelloWorld.jsp

test.ear\test.war\WEB-INF\lib\test.jar.

customization.

.

3



Page 04 of 7

when build patch#2, helloword.jsp is based on version

version# ##66

c: common patch#...