LV 8.5: An SCC Oddity

[Daklu]

So I'm fairly new to SCC systems having only minimal exposure to the Tortoise SVN client recently and MS VSS over eight years ago. I took the plunge and installed Perforce and the P4V client to maintain my source code. I've read through some of the posts by gmart and have a better understanding of the Perforce way, but there are still a few things I find confusing:

1. When I checkout code, I would expect a copy of the repository to be placed somewhere on my computer where I can edit it. With Perforce I have to copy the code from the repository to my working directory, then check it out. If I try to checkout code that does not already exist on my computer I get an error. Is this how it is supposed to work?
   
2. When I checkin code, I would expect the code to be moved from my working directory to the repository. Perforce leaves it there. If I want to edit the code I need to check it out again. (Unless, of course, I check the 'keep checked out' option.) Weird. It is very counter-intuitive.
   
3. On several occasions I have checked out a project, edited it, and tried to save it only to find I "don't have permission" to save that file. I assume that is because Perforce has marked it as under source control. Does that mean every time I want to save the file I have to check it back in? That would get really ugly, really fast.
   
4. Workspaces -- How do you organize your workspaces? Do you create a different workspace for each project you work on or have only one workspace for all your projects?
   

Thanks!

[Norm Kirchner]

Well I'll just say I don't know anything about workspaces.

As far as the other things, I have a wealth of info to share..... well maybe a clearance rack of info.... but regardless.

The way P4 works is that you should maintain a copy of the entire depot {or at least the relevant portion} on your PC.

The way P4 works is that you're local PC should have all needed files and the server has all versions of all files.

When you check out a file, it merely informs the server that you have checked out the file and changes the permissions on your PC from read only to full; there are no file copies that happen during a check-out. During check-in it will copy your file to the server, save it there, flag it a the head revision, and your PC will also have the head revision.

If you want a different version than the one you have on your PC, tell the server, your client will download it and the server will keep track of what version you have.

So checking out does not get you a copy, it merely informs the server that you are checking out the file; which you can lock so others can not submit over you. If the file is not on your system yet, you would Sync, that file to head on your PC. So you can't check out a file that you don't have a version of yet. Sync-to-head then check out.

the "keep checked out" option is so that while you are working on a file, you can make an intermediate version on the SCC depot and continue editing. It's like frequently saving any other type of file that you're not done with, except that it's version controlled.

Perforce really doesn't mark files in any way except through the read-only flag.

What kind of project are you checking out? LV Project?

If you have the lvproj file checked out, you can save it as many times as you want w/out checking in.

Hope this helps ~,~

[silmaril]

QUOTE(Daklu @ Jan 10 2008, 02:48 AM)

So I'm fairly new to SCC systems having only minimal exposure to the Tortoise SVN client recently and MS VSS over eight years ago. I took the plunge and installed Perforce and the P4V client to maintain my source code. I've read through some of the posts by gmart and have a better understanding of the Perforce way, but there are still a few things I find confusing:

That's no surprise! A lot confusion arises out of different terminologies used by LabVIEW, Perforce and SVN.

I tried to make a list of the most important terms:

LabVIEW             | Perforce              | SVNGet latest Version  | Sync to head revision | Check outCheck out           | Open for edit         | Get lockCheck in            | Submit                | Commit

(Sorry, I didn't find any decent way to make a table or to simply write preformatted text.)So the first step you will want to do in most cases is get a copy of the complete project onto your machine. This is "Sync" in P4.While working you keep checking in and out in LV or doing "Open for edit" and "Submit" in P4.Hint: you can configure your Perforce server so that it puts a lock on all LV files (based on their extensions) every time they are opened for edit.It also helps if you configure LV to "treat read-only VIs as locked". When you then open a VI, it's in run-mode. If you want to edit it, you hit Ctrl-M and two times Enter and the VI is checked out (opened for edit). The two enter keys are for acknowledging two message boxes asking if you want to change to edit mode and check out the VI.

QUOTE(Daklu @ Jan 10 2008, 02:48 AM)

How do you organize your workspaces? Do you create a different workspace for each project you work on or have only one workspace for all your projects?

I have only one large workspace with access to our complete depot. This enables me to sync a co-worker's project quickly without any need to configure a new workspace. But I have to make shure that I never ever sync the complete workspace

[Daklu]

Thanks for the replies. I'm definitely learning more as I go along but then I hit roadblocks that stump me.

1. Is there a way to create a directory structure in depot other than by creating it in my workspace and adding it? I'd really like the depot to have an organized structure but have each project directory in the depot, which may be several layers deep, to map to a directory in my root workspace. I've played around with the mappings but so far haven't been successful.
   
2. I successfully got my projects in the depot. To experiment I went back and deleted the files in my workspace. The process for getting the files back into my workspace seems awfully weird. I have to go into my depot and check out the files I want followed by reverting them. Only after I revert them will they be copied to my workspace. Then of course I need to check them out again. Isn't there a more straightforward way to do this? (Edit: I tried "Get Latest Revision" but that didn't do anything.)
   

(FYI, I was doing all this through the P4V client program, not Labview.)

[Norm Kirchner]

There is no way to add an empty directory in P4

Really, there is no structure like that in the depot, it assembles it as you add files.

So in order to pre-define directories and structures you would have to have a dummy file in each of the lowest branches of the dir treee

[silmaril]

As Norm already pointed out: you cannot have empty directories in the Perforce depot.

Perforce simply doesn't know any such thing as a directory. It's all "files with long names", where a name may be something like "//depot/Dir1/dir2/myfile.vi".

In some cases those files are displayed in a way similar to directories.

But you can - of course - have files in the depot that are not in your workspace. This is the normal case, since usually you are not the only person working with the P4 server.

I'm not shure if the following is 100% the same in P4V, since I am using P4Win (which seems to be almost the same, but more Windows-style to me):

Don't delete any files that are in P4 using Windows Explorer!

Instead select the files (or directories) you want to get rid of in P4Win, right-click and select "Open for Delete" (they must not be open for edit at this time!). This deletes them immediately from your local disk, but not from the depot yet. Deletion in the depot happens when you submit your changelist, which contains a new "delete" action for every deleted file.

If you do this, your files are not really deleted from the depot. They only get a new head revision in which they are deleted. You can always sync to an older revision to get them back.

If you are working under Windows I recommend installing P4Win, even if you prefer to use P4V. With the newer versions of P4Win you get a nice Explorer integration. It's not as powerfull as TortoiseSVN, but it's still something I wouldn't want to miss in my everyday work.

Since you seem to be used to SVN, let me point out just another tripwire that is waiting for you:

SVN's algorithms seem to work on a directory basis mainly. If you add a new file to a directory, it will be sent to the server with your next commit (at least that's what I remember).

Since P4 doesn't know directories, you have to make shure to add every new file to the depot. LV helps you very much, if you work with projects, but there might be one file or another that you are missing. Sometimes it's a good idea to add the complete project directory to P4 manually. This results in many "can't add existing file" warnings, but it will also add all the files you missed. Just be carefull with the files you don't want to have in version control (like LV's alias files, which you won't want on another PC in most cases).

[i2dx]

I had the same problem almost a year ago. I also tried (hard) to get comfortable with Perforce but finally I decided that Perforce is not suitable for me and removed it from my disks .... that was the nice version: In fact I am convinced that Perforce is just crap. I've never used a piece of software that made me more headaches than this one! This "workspace and change-list stuff" really drove me crazy.

The sad thing is, that VSS has no trial version, so what I do now is: use some (self written scripts) which retrieve my LabVIEW work directory once a day, and make a backup. Maybe this solution is not that secure but it is comfortable and at least I have "some" security. I decided to write my own SCC for LV, but this project is idle until I have more time - which will probably happen not before 2056

Maybe you want to check out CVS/SVN but I - for my part - am to lazy to set up a linux server and get it running - sorry, but I have still to much work

[Karl Rony]

QUOTE(i2dx @ Jan 11 2008, 05:09 AM)

I had the same problem almost a year ago. I also tried (hard) to get comfortable with Perforce but finally I decided that Perforce is not suitable for me and removed it from my disks .... that was the nice version: In fact I am convinced that Perforce is just crap. I've never used a piece of software that made me more headaches than this one! This "workspace and change-list stuff" really drove me crazy.

The sad thing is, that VSS has no trial version, so what I do now is: use some (self written scripts) which retrieve my LabVIEW work directory once a day, and make a backup. Maybe this solution is not that secure but it is comfortable and at least I have "some" security. I decided to write my own SCC for LV, but this project is idle until I have more time - which will probably happen not before 2056

Maybe you want to check out CVS/SVN but I - for my part - am to lazy to set up a linux server and get it running - sorry, but I have still to much work

I went with SourceGear's Vault at www.sourcegear.com. I tried Perforce but decided against it. It is far more powerful and complicated than I need. My brother switched from VSS to Vault for his company. I trust his judgement and he can help me when I have problems. I'm new to version control integrated in LabVIEW and I haven't worked too much with it yet.

Although Peforce offers a 2 user license for free, the product was $800 per user when I looked. SourceGear offers one user license for free and licenses is $250 per user. I also like the SourceGear owner's blog at software.ericsink.com.

Vault runs in the MS world with in a MS SQL database. It works with MS SQL Express or the MS SQL 2005. I prefer to stay in the Microsoft world as well.

If I recall, I think I had trouble integrating an earlier version of Vault with LabVIEW 8.2.1 on MS Vista. LabVIEW didn't recognize the SCC provider. I have no trouble with LabVIEW 8.5 on MS Vista with the latest Vault version.

[Norm Kirchner]

QUOTE(i2dx @ Jan 11 2008, 04:09 AM)

In fact I am convinced that Perforce is just crap. I've never used a piece of software that made me more headaches than this one! This "workspace and change-list stuff" really drove me crazy.

Wow! I have to say that's the first time that I've heard crap and p4 in the same sentence other than "most other stuff I've used is crap but then I started using P4."

Really all you need is 1 workspace and the realization that you are working on local files. And when it comes to LV I would not want to work on anything remote or especially have to re-download all copies of files from a location to work on a program. ech.

Daklu,

What is the general topology of the number of clients and number of projects that you'll be using? 1:1, 1:many, etc?

[CaseyM]

QUOTE(Daklu @ Jan 10 2008, 02:59 PM)

I successfully got my projects in the depot. To experiment I went back and deleted the files in my workspace. The process for getting the files back into my workspace seems awfully weird. I have to go into my depot and check out the files I want followed by reverting them. Only after I revert them will they be copied to my workspace. Then of course I need to check them out again. Isn't there a more straightforward way to do this? (Edit: I tried "Get Latest Revision" but that didn't do anything.)(FYI, I was doing all this through the P4V client program, not Labview.)

If you delete your files without using Perforce, Perforce has no idea that you don't have the latest version. To get the latest version choose "Get Revision..." from the context menu and then specify that you want to "Get latest revision" and then check "Force Operation". That should get the files back from the depot into your workspace.

[Daklu]

Right now it's only me using the depot installed on my laptop. I anticipate moving the depot to the same server that hosts my Labview installation files sometime in the not-too-distant future. There is an outside chance additional users (maybe 5-10) will be storing their Labview source in the depot once I do that. (In fact, we have enough key Labview tools right now that I'm going to encourage it.) In general we will not be having multiple people working on the same project, but each engineer has several projects going at any one time.

Just to throw a little twist in, I'm currently contracting at Microsoft meaning I could easily get VSS free. When I was looking at that I came across some comments about having to embed some text in the vi's to prevent corrupting the depot. It was a while ago so I may be misremembering, but it was enough to scare me away from that solution.

I really do like the SVN option since it is more intuitive for our main users, engineers. Unfortunately I suspect running Apache on corpnet would violate IT policy. Apparently SVN can run under a separate server that doesn't require Apache, but I don't know enough about that to say whether or not it will work.

QUOTE

Instead select the files (or directories) you want to get rid of in P4Win, right-click and select "Open for Delete" (they must not be open for edit at this time!). This deletes them immediately from your local disk, but not from the depot yet. Deletion in the depot happens when you submit your changelist, which contains a new "delete" action for every deleted file.

Doesn't this leave an open changelist waiting to be submitted? I think it would annoy me having semi-permanent changelists cluttering up my interface.

[Norm Kirchner]

QUOTE(Daklu @ Jan 11 2008, 12:24 PM)

Doesn't this leave an open changelist waiting to be submitted? I think it would annoy me having semi-permanent changelists cluttering up my interface.

If you want to delete a file, yes, it's a 2 step process.

mark for delete on your client

submit changelist which informs the server that head revision of the file is deleted

[i2dx]

QUOTE(Norm Kirchner @ Jan 11 2008, 05:25 PM)

Wow! I have to say that's the first time that I've heard crap and p4 in the same sentence other than "most other stuff I've used is crap but then I started using P4."

I've been using VSS for to long ...

(just my 2 cents ...)

QUOTE(Norm Kirchner @ Jan 11 2008, 08:58 PM)

If you want to delete a file, yes, it's a 2 step process.

mark for delete on your client

submit changelist which informs the server that head revision of the file is deleted

... I never got that working ... (that's one of the reasons ...)

[David Boyd]

QUOTE(Daklu @ Jan 11 2008, 01:24 PM)

... I could easily get VSS free. When I was looking at that I came across some comments about having to embed some text in the vi's to prevent corrupting the depot. It was a while ago so I may be misremembering, but it was enough to scare me away from that solution.

Perhaps you were recalling comments made about using VSS keyword expansion tags inside VIs? The catch is that the keywords must be of the fixed-length type to avoid corruption of the VI file, which is a binary stream. I'm sure in the past I posted here or on NI forums, or possibly Info-LabVIEW, about using such VSS keywords in VI descriptions (though they could potentially be placed anywhere, as BD or FP free text, BD constants, etc.). There are many useful keywords, f'rinstance:

$Author:$$ModDate:$would possibly expand to$Author:dboyd$$ModDate:2008-01-11 19:17$

but to use them in a VI you need to specify them as (note the double-colon):

$Author::		$$ModDate::				 $

so they'll always occupy a fixed bytelength when VSS expands them.

Is this what you meant?

Best regards,

Dave

[silmaril]

QUOTE(Daklu @ Jan 11 2008, 07:24 PM)

Doesn't this leave an open changelist waiting to be submitted? I think it would annoy me having semi-permanent changelists cluttering up my interface.

No!

Open for delete is a change that appears in the changelist.

Then you submit the change to delete it on the server.

Maybe you don't want to delete it on the server, just remove it from your client?

Then the option you are looking for is "Remove from client".

This doesn't change the deopt at all, it only removes your local copy from your HD.

QUOTE(Daklu @ Jan 11 2008, 07:24 PM)

Right now it's only me using the depot installed on my laptop. I anticipate moving the depot to the same server that hosts my Labview installation files sometime in the not-too-distant future. There is an outside chance additional users (maybe 5-10) will be storing their Labview source in the depot once I do that. (In fact, we have enough key Labview tools right now that I'm going to encourage it.) In general we will not be having multiple people working on the same project, but each engineer has several projects going at any one time.

The depot on the laptop is nice to test P4, but I would strongly recommend to run the P4 server on a computer in the network. Then throwing your laptop on the ground won't destroy your depot

Even if you only have 1-person-projects, I find it very usefull to use an SCC tool. One more thing you should think about are regular backups of your depot. If you succeed in convincing several people to use your SCC server (no matter which product you actually use), those people will rely on the server as a backup for their source files.

Imagine what happens if there is a head crash on the server's harddisk!

QUOTE(Daklu @ Jan 11 2008, 07:24 PM)

I really do like the SVN option since it is more intuitive for our main users, engineers. Unfortunately I suspect running Apache on corpnet would violate IT policy. Apparently SVN can run under a separate server that doesn't require Apache, but I don't know enough about that to say whether or not it will work.

I am running P4 at work and Tortoise SVN at home. Both are running under Windows XP. Both are working fine for me.

The only thing I don't have is the PushOK extension for SVN, so I don't have LV integration at home (which is a bit uncomfortable but not the end of the world).

SVN is running without Apache. If you want to try it yourself, I recommend installing Tortoise SVN and looking at it's help file. Have a look at the section "Setting up a Server >> Svnserve Based Server". It looks a bit complicated at first, but in the end it's only a small list of steps you have to follow. As long as you are not afraid of the command line, I don't see a problem ;-)

I find it astonishing to see how much you can get for free using SVN! It looks like a really mature piece of software.

Still there is at least one reason for P4: If you have to maintain older projects with LV 7.1 or earlier, you cannot get LV integration with anything else than P4 or MS VSS.

[Daklu]

You guys are great! Not only do I get my questions answered, but I get answers to the questions I didn't know to ask! :thumbup:

It turns out I'll probably skip the Perforce solution and go with SVN/Tortoise. The biggest advantage of Perforce is the Labview integration, and since most of our licenses are Full I don't think they can integrate scc anyway. Plus $800 a seat is a big pill for my manager to swallow... especially when there are internal solutions we could get for free.

QUOTE

Have a look at the section "Setting up a Server >> Svnserve Based Server". It looks a bit complicated at first, but in the end it's only a small list of steps you have to follow. As long as you are not afraid of the command line, I don't see a problem ;-)

Usually I can figure things out so I feel like an idiot asking the question, but which binary am I supposed to download? Tortoise 1.4.7 is supposed to work with SVN 1.4.6, which I can't find. I see 1.4.5 and various dev libraries for 1.4.6... ?

[Ton Plomp]

QUOTE(Daklu @ Jan 15 2008, 12:25 AM)

It turns out I'll probably skip the Perforce solution and go with SVN/Tortoise. The biggest advantage of Perforce is the Labview integration, and since most of our licenses are Full I don't think they can integrate scc anyway.

Well if you can integrate with an SCC, you could consider http://forums.lavag.org/index.php?showtopic=9604&view=findpost&p=38951' target="_blank">PushOK, one downside is that the repository has to reject anonymous browsing. Somehow the plugin isn't triggerd to use a user when performing edits.

Ton

[silmaril]

QUOTE(Daklu @ Jan 15 2008, 12:25 AM)

Usually I can figure things out so I feel like an idiot asking the question, but which binary am I supposed to download? Tortoise 1.4.7 is supposed to work with SVN 1.4.6, which I can't find. I see 1.4.5 and various dev libraries for 1.4.6... ?

On http://subversion.tigris.org/ under "Latest Release" you get to this page: http://subversion.tigris.org/servlets/News...newsItemID=2007

I don't know why the URLs there are no links, but downloading them via copy-paste works fine.

[Andy Peters]

QUOTE(i2dx @ Jan 11 2008, 03:09 AM)

Maybe you want to check out CVS/SVN but I - for my part - am to lazy to set up a linux server and get it running - sorry, but I have still to much work

It is not necessary to set up a Linux server for your Subversion repository. If it's just you, working on your own projects, you don't even need a server; you can access the repository using the file:// semantics.Here at the office, I have the Subversion server running as a service on a WinXP box. It was a snap to set up. It doesn't require you to build Apache or any of that. Grab the latest binaries from here and following the instructions here. You access the repository using the svn:// semantics. I can access this repository from anywhere on the company network.At home, I have a Mac mini serving the repository using Apache. This was a bit tricky, as at the time, OS X did not ship with Apache2. However, Apple does have instructions on how to build Apache2 and Subversion, which worked and all is well. Now I am running Leopard, which includes Subversion and Apache2. I kept the custom-built copy of Apache2 (which included the mov_dav stuff required by svn) because it just works. The Apache daemon serving svn listens on a non-80 port. The repo is accessed using http:// semantics and I can get to the repo from anywhere on the internet.good luck,-aQUOTE(silmaril @ Jan 11 2008, 02:40 AM)

SVN's algorithms seem to work on a directory basis mainly. If you add a new file to a directory, it will be sent to the server with your next commit (at least that's what I remember).

Yes, that's true. Also, if others are working on the same project, or if you develop on more than one machine (as I do), make sure that you do an svn update before working, so that you always have the latest versions of all files. You REALLY want the latest versions because merging VIs is ... rather impossible!-a