![]() ![]() A comparison of two repos seems only to be possible in a optical(!) way Before pulling changes out of a partner repo it is not possible to review the imported revisions before pulling them.Sometimes the algorithm ends up in a wrong result. Renaming of files/folders cannot be influenced! This type of info is not stored within the repo and is re-detected every time the repo is viewed.It is possible to send single branches to another Bare-Repo (or be imported from another Repo) => Way of thinking in "Heads".History can be changed/rebuilt (single revisions can be deleted/changed).It is not possible to check-in empty folders / folder structures.It is not possible to check out and commit single folders into the repo (if you have a big repo and want to have only a small part of it).Idiot safe - with standard installation it is not easy to destroy a repo.Simple installation without many questions, consumes less than 100MB of hard disk space.The history can easily be changed using the Extension "mq" - wrong check-ins or branches don't have to stay in the repo forever but can be deleted - but be careful: this will lead to different checksums and therefore to new branches in cloned repos.TortoiseHg installs a "Workbench" automatically.There is no annoying distinction between bare and non-bare repositories (in contrast to Git) -> Sending of revisions to partner repo is possible even in checked-out state, because only the history of the partner repo is affected (in contrast to Git).Shelve is a ingenious function to save several (unrevisioned) changes temporarily (in that way neither in SVN nor in Git ("Stash") available).Before pulling from or pushing to another Repo it is possible to review the affected revisions (and abort the action if necessary).Newest version still runs in Windows XP.There are revision numbers as well as revision checksums ("Hash") available (easier orientation for humans than e.In TortoiseHg-Workbench all revision trees are displayed (contrary to Git).Renaming of files can be defined manually as well as detected automatically (in a special dialog => algorithm: similarity check of file content).The last checked-in revision cannot be changed / amended / rolled back.No distributed version management System (you always need to have connection to the server-repo).Possibility to check-in empty folder (structures).Revision comments and revision username can be changed at a later time without changing/influencing any checksum or revision ident number. ![]() Possibility to check out only a part/subfolder of the complete repository.Here is my conclusion: TortoiseSVN / Subversion (SVN) So we now have the challenge, this is all very possible IMO.During the last years I used all three Version Management Systems (TortoiseSVN, TortoiseHg, TortoiseGit) and tested them thoroughly. Some search, bug reporting and registration interfaces would also be useful. Additional info would be version data I reckon. You could also push back requests and updates for a toolkit.Ī nice user interface for this would be a palette of toolkit repos that you can include into your project and this needn't be much different than the palette view currently available. The VIs will from all the linked repos will be checked out as you would normally checkout a project, but there will be notifications if a toolkit can be updated. So for now let's talk just about a repo and external links to other repos.Ī project will have links to a version of a toolkit, dependency or library (including a hash number for traceability). The presentation that filled me with enthusiasm at CSLUG was given by Greg Payne and he talked about was Git Submodules (SVN External Items may also work). Managing re-use across projects is cumbersome and manual.Every project is self-contained in the repo.This sorted out the control but made re-use a little cumbersome, so I would mark it as about 8/10. Various techniques for handling this issue were discussed and at SSDC we settled on making all of our projects atomic (various articles and presentations describe this). But to summarise I expressed the opinion that the current and LabVIEW model for reuse sucked and explained that you can have source-code control where project code is in the repo, but if the dependencies (user lib, instr lib and even unprotected vi lib files) weren't also under source-code control a high-percentage of your code could be modified without control. If you've not read the aforementioned article I strongly recommend reading it and also all the comments too. Here's a link to his article on the topic I think it might be worth revisiting this and talking about something Greg Payne brought up in CSLUG the other month. (Re-use) Part 1" and amongst the 20 or so people that care about such things it caused a bit of a stir. Over 4 years and a 100 articles ago I wrote "I'm not being critical but.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |