![]() I mean, I have recently used GNS3 for training, but as a teacher, not as a student. I'm mostly in the minority of GNS3 users there. The files are still the same (not saved a second time), but the revision logs show them having appeared once more.īut that last characteristic is precisely the solution to what I perceive as a "problem" of the snapshot system in 0.8.7. However, IF there are any commits between the current version and the one you're restoring to, then you're right - the revisions between the restored one and the current one will be kept, and a separate commit will be added on top. They store entire files upon commit, so when you restore a version from an uncommitted one, they remove the uncommitted files, and copy the repository files into the tree, thus preserving not just the original file, but also its meta data (if that's what you're worried about when you say "modifies the current version to look like the old version"). I don't know about Mercurial and other "changeset" systems, but "snapshot" systems like Git, AFAIK, don't do that. It is more like an auditing system - if you "restore" an old version, it actually modifies the current version to look like the old version - and you can quickly end up with lots and lots of versions if you say try to restart an exercise from scratch four or five times. I don't have an objection to adding a version control system to GNS3 sometime in the future, but let's not compromise the Snapshot system to do it. So in conclusion, I think the Snapshot system should be implemented as I described above, based on the behaviour of the existing (v0.8.7) system. None of this kind of activity does suits a version control system. A lab can be created that has many different snapshots to restore, each presenting a variation of the same problem, and even a snapshot that loads the solution. It allows a user to restore a snapshot at the start of a lab exercise, and if they want to, they can start the lab again by restoring the same snapshot. I believe the vast majority of GNS3 users are using GNS3 for study or learning purposes Īnd for people studying or learning from labs such as GNS3 WorkBench, the existing snapshot system (which took three years to refine and get to the stage where it is now starting in about sept 2010 and finally working in 0.8.6 based on topic6581.html) probably works better than a version control system. And if it were to be truly mimic your real-world install, then it could also be useful there.īut I don't believe the vast majority of GNS3 users need or want that. So for a developer trying to work out a complex set of configurations for a particular topology, a version control system may be useful. I'm not a programmer (any more) but my (possibly flawed) understanding of a version control system is that it doesn't work like that. In the parlance of storage systems and of VMware, when you restore a snapshot, it replaces the original. I do some work with VMware and various disk arrays. However, I think version control serves a different function than snapshots. I thinks that pretty well says it all - I don't see any need to make any other changes to the way it used to work, apart from perhaps in the Manage snapshots dialogue, it would be nice to be able to double-click on a snapshot and assume that you meant can see that a version control system for GNS3 could appeal to some people. #Note3: The snapshot contains exactly the same structure as under the Demonstration Lab directory, apart from the snapshots directory With a bunch of directories under it would sometimes give errors on Windows PCs because the filepaths could get too long #Note2: The directory name for the snapshot is much shorter than the old GNS3, but still holds all the important information - I found at times that with directory names like: #Note1: the snapshots directory is under the Demonstration Lab directory For the following, assume that I have taken a snapshot called 0 Initial Configuration in my project called Demonstration Lab, which consists of a single router with two PCs The snapshot was taken on at 08:51:21 I think the simplest way is to draw what I see should be the directory structure when a snapshot is taken. So until V1 has Snapshots, I'm at a standstill.īut it has lead me to think about how I think Snapshots should be implemented in GNS3v1 However, the WorkBench exercises are built around Snapshots. Snapshots are a feature dear to my heart, and I've been trying to get my GNS3 WorkBench labs converted to v1 format so that we can put something under
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |