Jump to content

Project Sharing and Committing & Releasing


Recommended Posts

I'm new to Project Sharing and, so far, I think I understand most of it.  Except for whether or not all items always need to be released simultaneously...

 

If you commit and save the changes you've made to a working file, that doesn't seem to affect what you've checked out.

 

But if you release an item, such as a layer or an object, it seems necessary to both commit all the changes you've made in the working file and to release all items that have been checked out.  This seems consistent with Vectorworks Help, which says that when releasing an item "All layers and objects you have checked out are released" (see here).  So, okay, but...

 

What, then, is the purpose of releasing objects based on criteria?  What's the point in selecting certain items to release, if all checked out items have to be released together anyway?...

 

What am I missing?...

Link to comment

Welcome to the adventure of project sharing! Project sharing is extremely helpful, but (as with any tool) some functionality can be confusing.

 

The quick answer is that it IS possible to release only some items at once...if you go through the correct steps. Objects or layers must be saved and committed to the project file before you can release individual objects or layers via the right click context menu, modify menu, or custom release. For example, a more detailed explanation:

 

I have the circles and polygon checked out (as you can see by my purple user outline on the objects) and have edited something about them:

1323156409_Picture1.thumb.png.18322cea691a4e953a5046f123fe1333.png

 

If I try to right click on one of the circles to try and release it individually, I would get the message you were finding:

1368923679_Picture2.thumb.png.2f4e6697866cd0640ede7349f2fef861.png

 

This is because any changes to objects within the working file must be saved and committed to the project file before being able to be released. The only option is to commit all changes or discard all changes at this point because Vectorworks does not have the ability to save and commit individual items or layers. Therefore, if you want to release an item, Vectorworks has to save and commit your entire working file to the project file (and apparently, through this specific menu, releases all items as well). So, this isn't the functionality we are looking for. The process to make individual/custom releases is as follows:

 

After working with all your objects/layers, go to File->Save and Commit. When the menu comes up, uncheck the "automatically release checked out layers and objects":

848161344_Picture3.thumb.png.66bf3ef508cf953a3f1f5af2f78e2582.png

This will save and commit all of your changes to the project file, but will not release any of the objects or layers you have check out. Vectorworks will remind you of this with the following pop-up:

10353762_Picture4.thumb.png.c4acc78e16fdfe6e85187ce2d63d18a4.png

So, now anyone else working on the project can see my circles and polygon, but they can't edit them as I still have them checked out. A much more realistic example is if I was adding walls to a building and wanted my team to be able to see them, so they could work on other aspects of the project, but I wanted to maintain my ability to change the walls if needed.

 

Now (since I've saved and committed), if I wanted to release just the circles, I could right-click on each circle and pick the release option, select both circles and go to Modify->Release, or perform a custom release like the picture below:

1577898016_Picture5.thumb.png.66918c4302ea7060b18ca74aa235a04f.png

 

Now my circles have been released back to the project file and other members of my team can check them out. I know this as the circles no longer have my purple user color outline:

1426341342_Picture6.thumb.png.571bffe6ae989dd11fc76efa321e1ea6.png

 

Hope this helps!!

Eliot

 

  • Like 3
Link to comment

Thanks so much for your thoughtful & thorough response!  It all makes sense now.  In a nutshell, all changes need to be saved and committed before items can be individually released.

 

If only that "Do you want to commit or discard all of your changes?" message made that clear, or, even better, included options to either "Release only these objects or layers" or to "Release all checked out layers and objects."

 

Thank you!  

Link to comment

You're welcome, glad I could help.

 

20 minutes ago, willofmaine said:

In a nutshell, all changes need to be saved and committed before items can be individually released.

Exactly.

 

21 minutes ago, willofmaine said:

If only that "Do you want to commit or discard all of your changes?" message made that clear, or, even better, included options to either "Release only these objects or layers" or to "Release all checked out layers and objects."

I would agree, that pop-up is not as straight forward as it should be because it only speaks to half of the action that is going to take place if you click the "Commit" button. In the File menu of VW, the save and commit command does only the action of syncing the working file with the project file. But on this pop-up, clicking the "Commit" button is actually performing two separate tasks, both a save and commit and a release all objects/layers. The part about releasing all objects is missing from the description on the pop-up.

Link to comment

So... I just committed changes to a project file so that I could release everything, but, for some time the team had no access to the project file (and Dropbox was syncing for a long while).  I'd assumed that when committing changes, only the changes would be written to the project file.  Is that not the case?  It sort of seems like the entire project file is being overwritten (200 MB = time consuming...).

 

Otherwise, the ability to release things individually is going well!

  • Like 1
Link to comment

Hey @willofmaine

 

Glad to hear that the individual release functionality is working well for you!

 

3 hours ago, willofmaine said:

I'd assumed that when committing changes, only the changes would be written to the project file.  Is that not the case?

To speak of project sharing in general, this depends on the type of storage being used. For Dropbox, your assumption is correct in that only the changes are synced back to the project file.

 

If you had to estimate the "some time" you mentioned, what would it be?

Link to comment

I just had to commit the file again, and Dropbox is syncing over at least 190+ MB (file size is 204 MB at Dropbox).  Also, oddly, there is no blue Dropbox syncing icon adjacent to the file (though the container folders do have them, and everything else has their green checks as expected...).  It's looking for about 20 minutes to update.  Did I miss a setting somewhere?  This is not super ideal...  Thanks!

Link to comment

Maybe the Network Protocol at Project Sharing Settings should be "Share Project File using SMB only" instead of "AFP" (currently selected) (whatever those are...).

 

Might it be the backup file getting replaced (it's located in Dropbox in its own folder next to the project file)?  Only problem with that theory is it's set to backup after every 5 commits, and we've only committed twice today, and both times were similarly problematic...

 

Can I just delete the project file and create a new one from scratch (from a current, up-to-date, refreshed working file)?  And, for the heck of it, maybe following some communication with the rest of the team... ... ...

 

 

Link to comment

I would move the backup files to the local hard disk and not keep them on Dropbox. Especially if you are using the Autosave a backup copy to option. I believe that is going to generate a new file each time rather than just make changes to the previous version(s). So on Dropbox with the backups going to have to fully sync every time rather than just the delta in the file.

Link to comment

The time and amount of data transfer you mention above indeed seems quite odd. We've seen a file of this size take up to a few minutes to sync, but not 20. The number of items that have been added or changed, as well as CPU and internet speeds can all play into this though...

 

As Pat mentioned, and the thread he shared discusses, when properly implemented Dropbox uses Delta Sync to only sync the changes from the working file to the project file. Nothing that I can find talks about having to set up settings within Dropbox for this to happen though, it's automatically integrated, so I can't point to anything here....

 

9 hours ago, willofmaine said:

Maybe the Network Protocol at Project Sharing Settings should be "Share Project File using SMB only" instead of "AFP"

As discussed in the Knowledge Base article that you found, SMB is now the preferred protocol for either OS, so if you are currently using AFP it might be an OK idea to switch to SMB.

 

9 hours ago, willofmaine said:

Might it be the backup file getting replaced (it's located in Dropbox in its own folder next to the project file)?  Only problem with that theory is it's set to backup after every 5 commits, and we've only committed twice today, and both times were similarly problematic...

I had thought about this as a possibility as well, but if you have the project sharing settings set to backup every 5 commits, this is most likely not the issue.

 

9 hours ago, willofmaine said:

Can I just delete the project file and create a new one from scratch (from a current, up-to-date, refreshed working file)?

Just want to be sure and clarify something here. If you are going to create a new project file from your existing working file, make sure everyone has committed and released their changes and that you have refreshed you working file as you said, then you want to "Save A Copy As" and choose a normal vwx file extension. You can then make a new project file out of that file and your team can get new working files from this new project.

 

I would say try to create a new project file and see how it goes. Check out this specific post from the thread above for general Dropbox guidelines just to double-check, then go about creating a new project file using SMB. 

Link to comment

I did switch to SMB, but to no avail.  But, also based on Jim's article, it looks like the current Mac OS is recommended.  I'm on High Sierra (I've developed an aversion to what has often seemed like downgrading to the latest, "greatest" Apple OS...)...  And it looks like Vectorworks 2018 doesn't run on Catalina, so, last night I "officially" switched to VW 2020 (transferred Libraries, etc.).  So, I am apprehensively moments away from upgrading to Catalina; hopefully that will resolve this issue!!

 

I can check everything off in that general Dropbox guidelines post you referenced.  And your explanation of how to create a new project file - we are very much on the same page!

 

Again, thank you very much for your thorough responses.  I will let you know how it goes with Catalina.

 

 

Link to comment

I've installed Catalina.  I've uninstalled and reinstalled Dropbox.  I've recreated the project file from scratch.  I've created brand new project files from small test projects.  All to no avail.  No matter what I do, Dropbox syncs the entire file with each and every commit.  At one point I'd changed the backup location to my local drive, but then changed it back again.  That (or something) resulted in a couple of .bak files, along with the file in the Vectorworks backup folder.  Each of the .bak files (whatever those are) were a full 200 MB.  Searching on Google for "Delta Sync" mostly gets me results for Smart Sync, or maybe an explanation of what Delta Sync is.  But nothing about how to enable it.  

Link to comment

I guess now, maybe having reinstalled Dropbox, it's at least faster.  Maybe 4 or 5 minutes instead of 20.  In all cases, Dropbox appears to start with the full 200 MB, but maybe that's to be expected with "incremental" backups.  (The original 200 MB plain .vwx file takes about 20 minutes to upload).

 

But, it still seems like 4 or 5 minutes is quite a lot of time to Save & Commit after having only added a couple of circles and moved a rectangle (in my test working file)??... 

Link to comment

We've temporarily abandoned project sharing.  Did a "Save As..." to create a regular .vwx Vectorworks File.

 

Now, when I change the "None" class to "Use at Creation," (even though I'd already previously done this during project sharing...) and select "No" for changing the attributes of objects previously created, Vectorworks freezes, apparently until I start the "Force Quit" process and/or just right-click on its icon in the dock.

 

Worse, I can't update a section viewport that I recently created (during project sharing).  There's no progress bar, a spinning beach ball, and, ultimately, the Activity Monitor says that Vectorworks is not responding.

 

Project Sharing was looking great at first, but now I feel like it's plunged us into even more of a Vectorworks nightmare than is typical (which is a lot of nightmare...).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...