LVLIBs under SCC

[Vladimir Drzik]

Hi

In one of our projects, I am using a hierarchy of LVLIBs to ensure correct namespacing of each VI. That also means that the whole project is included in a single top-level LVLIB. For SCC, I am using MS SourceSafe with the locking check-out/modify/check-in model. So far, only a single developer worked on the project at once, so he could check out the whole project when doing changes. However, there is a big problem when multiple developers try to work on the project. Every time a new VI is created, at least the top-level LVLIB gets modified. This LVLIB can be checked out by one user only, which leads to endless conflicts.

Is there any good solution how to use namespacing via LVLIBs together with SCC?

Vladimir

[LAVA 1.0 Content]

QUOTE (Vladimir Drzik @ Oct 13 2008, 11:00 AM)

Hi

In one of our projects, I am using a hierarchy of LVLIBs to ensure correct namespacing of each VI. That also means that the whole project is included in a single top-level LVLIB. For SCC, I am using MS SourceSafe with the locking check-out/modify/check-in model. So far, only a single developer worked on the project at once, so he could check out the whole project when doing changes. However, there is a big problem when multiple developers try to work on the project. Every time a new VI is created, at least the top-level LVLIB gets modified. This LVLIB can be checked out by one user only, which leads to endless conflicts.

Is there any good solution how to use namespacing via LVLIBs together with SCC?

Vladimir

An LVLIB is a cohorent piece of code together with the subVIs, so treat them like one.

If you add a new VI simply do a fast check-in/out of the lvlib, this shouldn't take long.

Ton

[Aristos Queue]

You should allow multiple developers to simultaneously check out .lvlib, .lvproj, .lvclass, .xctl and .lvsc files. These files are text files that can be easily merge integrated. They were explicitly designed such that adding a VI to the files makes a purely localized change in the file (ie. there's no "total count" value that has to be kept consistent, and there aren't multiple sections of the file that change as the result of adding a single identity). If the programmer is going to make a change such as moving the file to a new location on disk, then he/she should actually lock the file.

[Vladimir Drzik]

Thanks for the suggestions. I am trying to follow the non-locking model, allowing multiple checkouts for text files. However, LabVIEW's SCC integration always makes exclusive checkouts. Which effectively prohibits me from using merging together with the SCC integration. Can you think of a way how to get around this?

Vladimir

[gmart]

QUOTE (Vladimir Drzik @ Oct 15 2008, 07:49 AM)

Thanks for the suggestions. I am trying to follow the non-locking model, allowing multiple checkouts for text files. However, LabVIEW's SCC integration always makes exclusive checkouts. Which effectively prohibits me from using merging together with the SCC integration. Can you think of a way how to get around this?

Vladimir

Typically, you can configure this within the SCC provider's client. If you are using the Perforce Command Line provider, in the Tools>>Options Source Control page, the option to not lock files is located as an advanced option.