Completely stuck

[Roger]

So I decided to dust of my project today and get back to working on it.

 

The problem is it has been so damn long since I've worked on it, I'm not entirely sure what are my most recent files. I have 3 different backups, I can sort by date and that should at least get me close but I'm not sure if there is other more recent stuff somewhere. I had everything on a 16gb jump drive and just about died because when I went to check it, there were none of my project files on it (forgetting that I'd moved them to a larger portable HD).

 

I feel like I'm going to spend hours just sorting through everything to make sure I've got the most recent stuff, and I've completely lost all motivation to do any work on it. At this point I'm considering just calling it a day and going to the gym so I will at least get some exercise.

 

I guess I'm also pretty upset with myself that I've let myself go this long without working on it, the last time I seriously did anything with it was a bit over a year ago.

Any suggestions for managing large numbers of files? I usually have several versions of the same model since I save several times while I am working on it, so I can go back to an earlier version if something gets screwed up. While I can do a date sort, and I try to give myself descriptive names so I know what is going on with a particular file, I'm not sure if I'm doing myself favors keeping all the work in progress stuff around. Maybe I'd be better served figuring out what is current, placing it in a project folder (making at least 3 backups) and then putting everything else in cold storage?

[Rodney]

Save often and save incrementally. That's what folks 'round here preach continually. It's that second part that people tend to neglect.

If you add that increment (a number or letter) to the end of a filename and/or folder it is considerably more easy to determine what the latest update is.

By no accident this follows general programming methods of versioning releases as well.

 

Your method of sorting by date should get you most of the way there.

Step away from the computer for a little while until you clear your head.

Otherwise you might fix something that doesn't need fixing in your haste to 'repair'.

 

Not everyone embeds their projects but let me say that there are good reasons to embed once you reach certain plateaus in a project.

Assuming of course you will be sharing these files with someone else, otherwise embedding is a lower priority.

 

Go hit the gym. Then come back and tackle this thing with a clear head.

[Roger]

Yeah, after looking through my files I realized that a 3 digit number in addition to the descriptive name may work much better for me ( I don't see myself having more than 999 versions of something, and if I do then I really should be pruning things a bit more often).

 

I don't want to embed the project files just yet, I'm not really sharing any of my data and I think that will cause me more problems with subversion.

[Rodney]

I don't want to embed the project files just yet, I'm not really sharing any of my data and I think that will cause me more problems with subversion.

 

I'm not sure if I follow you here.

Are you saying you already use Subversion?

[Roger]

I don't want to embed the project files just yet, I'm not really sharing any of my data and I think that will cause me more problems with subversion.

 

I'm not sure if I follow you here.

Are you saying you already use Subversion?

 

Maybe I used the wrong term, but I've accidentally embedded things in a project file, gone to edit another model/project and then noticed that all the instances of that model/project have been changed. For my particular workflow, this is not desirable. That may change at some point, but for now I prefer to have stuff not auto-update on me.

[Rodney]

for now I prefer to have stuff not auto-update on me.

 

I hear you and won't belabor the point.

I do want to try to clear up a little misconception though.

 

Keep in mind that embedding (in A:M) is actually a way to keep resources from auto-updating.** That's why I do it (that and to make sure files associated with a project don't get separated from that Project... which might lead to their inadvertent loss or update). When we embed files the only way things will update is if we save that Project (and since we'd optimally be saving that file under a new increment name) it would never overwrite or auto-update any older version. In this way embedding is likely the safest saving method in A:M of them all.

 

Just for info purposes, Subversion (which is completely separate from A:M but can be used by anyone for file storage) is one of many methods to automatically increment/iterate/version files that preserves data. Instead of keeping every file most of these progrms track what changes so that any previous data or version (hence the name subversion) can later be returned to again. In short, the program doesn't overwrite anything because it overwrites everything while tracking any change from the first time the file's state is recorded.

 

Not to confuse you but all of this is different than 'consolidation' which was added as a saving option in A:M because embedding only embeds native A:M file formats (it doesn't embed images, audio and other external formats). Consolidation accomplishes this by compressing all associated files into a zip file (and that file preserves the original file structure too so that it can later be replicated).

 

 

**A problem with NOT embedding is that unembedded files drive auto-updates every time ANY resource that is referenced is saved.

If for instance, we have a model that is referenced in 10 different projects and we change and then save that model, each and every one of those projects is going to be auto-updated the next time we open them (assuming the location of the file hasn't changed and broken the link of course!). This update occurs because the link in the file references the original (now changed) model.

With embedding this doesn't happen because the model is saved internally in that one Project file. Although... at any given time we can un-embed or change the referenced file also. Just because we opt for one solution doesn't mean we always have to do that.

 

Sorry if that is as clear as mud.

We have a whole lot of options available to us.

That is both bad and good.

 

There is enough confusion out there that many tend to shy away from features they would otherwise benefit from using.

 

I've accidentally embedded things in a project file, gone to edit another model/project and then noticed that all the instances of that model/project have been changed. For my particular workflow, this is not desirable.

 

This is the part that troubles me because technically (i.e. barring a bug or something not working as designed) this cannot happen.

Something else must have occurred and that's the kind of thing that makes any given workflow worth looking into.

[Roger]

I need to experiment with it and make sure I understand it fully before using it. I don't want to start using a feature if I'm not really sure how it is supposed to work.

[NancyGormezano]

Maybe I used the wrong term, but I've accidentally embedded things in a project file, gone to edit another model/project and then noticed that all the instances of that model/project have been changed. For my particular workflow, this is not desirable. That may change at some point, but for now I prefer to have stuff not auto-update on me.

 

I am going to guess that you didn't really have things embedded in a project file. But when you saved the project file, all the models, chors, materials, also get saved into their respective (external to project) files. So any changes you might have been experimenting with - get saved. And yes, any external projects referencing/using those same models, materials would be impacted, unless you saved them all to new names, which is what I do, eg material1, model1, chor1, etc (note: order of saving is important). Then external references won't be impacted and you can modify these elements without worrying about impacting other "jobs".

 

I never, ever work with projects, unless I am forced to just for that reason. (Some things require a project, for dumb reasons). I save my materials, models, chors all into separate files...but never save a project file (embedded or not), while still developing a "job". I will only embed all (models, chors, materials) into a project file (and then save the project file) when I am forced to share, or want to archive a finished "job".

 

If you had had everything embedded in the project, then any models, chors, materials in the project file also get updated whenever you save the project, but only that project would have been impacted (unless there was a bug).