> I know how to do it.* I'm just saying that from the point of view of > someone used to working within the Finder, it seems very strange and > rather inefficient. The way this seems to work, we have to perform > three steps to rename a file: rename in Finder, delete old (missing) > file from the project within Versions, add renamed (new) file to the > project within Versions.
Subversion (and Versions) has a 'rename' function that does this. It is in the right-click menu for the versioned file. > *Though I did have to figure it out by trial and error. Is there a > manual anywhere that tells me about the user interface of Versions, > what the numbers after the projects refer to, what the question mark > in the blue bubble means, etc.? There are tooltips that pop up after a while (maybe too long of a while) that say what those are. > What I'd like Versions to do is, when a folder is committed, notice > (as it clearly does) that some files are missing and *assume* that > this means the user intends to delete them (maybe even pop up a dialog > box asking for confirmation), and then pass Subversion the command to > delete these files. Similarly, if it notices on commit that there are > files present in the folder that aren't in the Subversion database, > I'd like it to *assume* that these files should be added to the > project as part of the commit. (Obviously this should be an option > rather than the only possible behaviour.) > > Or is this not the way Subversion should be used? If not, what should > I be doing instead when I want to add or delete files? I'd like to see the feature to automatically add as well. But the reason why this is not the default behavior has to do with the dominant use case, which is programming. It is common for your compiler or editor to make a bunch of a auxiliary or temporary files that live in the same folder as the files you really care about. So if you could make it automatically add things, you would get a lot of extra stuff in your repository that you don't need. If you're working in teams, you wouldn't want to deal with all the random things your colleagues put there, and vice-versa. Source code control isn't a fancy snapshot of whatever is on your disk. There are other tools for that, but I haven't used any for a long time since I have been conditioned to deal with subversion's neuroses. Subversion and other tools like it are social things that represent the combined efforts and maintenance of groups of people over time. The more it does automatically, the greater the risk that unwanted files sneak into the system. You said you were deleting and re-adding files under different names. In doing so you lost the history of a file because subversion doesn't know the connection between the old and new versions of the file. This probably doesn't really matter in your situation, but at some point in the future it might if you need to revert to a previous version of the file from before its name was changed. I wonder if there are tools similar to source code control but for media projects? -- ;; Gabe Johnson ;; PhD Candidate in Computational Design - Carnegie Mellon University ;; CoDe Lab: http://code.arc.cmu.edu/ ;; Personal: http://six11.org/ -- You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com. To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/versions?hl=en.
