Omdat door het in de verkeerde folder plaatsen ook references naar NuGet-packages verkeerd stonden, en de packages zelf dubbel zouden worden ingecheckt.
Ik snap dat een checkin, remap, get ook zou kunnen werken, maar dat werd in dit geval dus wat lastig en is alsnog nodeloos omslachtig. Ik snap die bindingen naar lokale paden gewoon niet, git en svn gaan ook niet op hun bek als je de working copy verplaatst. Zeker een SourceSafe-erfenis.
Daarnaast heb ik ook legio slechte ervaringen met remappen. Zoals toen VS/TFS het nodig vond om de topmost parent ook maar te remappen, terwijl ik dat drie mappen dieper deed, zodat ik een paar honderd MB aan sources weer opnieuw kon binnenhalen, wat ook weer een uur kost.
Edit: zie je wel.
Ik kwam niet voorbij de "The item {filename} is cloaked"-issue, dus heb handmatig eenzelfde map aangemaakt in TFS. Ineens bleek deze weer gemapt naar de oude directory. Wáár wordt deze informatie bewaard, als ik het lokaal aanmaken van die map niet heb ingecheckt én die map lokaal niet meer bestaat?
Maar eindelijk, ik heb een Remove Mapping kunnen doen en kan weer inchecken. Troep is het, allemaal!
Ik snap dat een checkin, remap, get ook zou kunnen werken, maar dat werd in dit geval dus wat lastig en is alsnog nodeloos omslachtig. Ik snap die bindingen naar lokale paden gewoon niet, git en svn gaan ook niet op hun bek als je de working copy verplaatst. Zeker een SourceSafe-erfenis.
Daarnaast heb ik ook legio slechte ervaringen met remappen. Zoals toen VS/TFS het nodig vond om de topmost parent ook maar te remappen, terwijl ik dat drie mappen dieper deed, zodat ik een paar honderd MB aan sources weer opnieuw kon binnenhalen, wat ook weer een uur kost.
Edit: zie je wel.
Maar eindelijk, ik heb een Remove Mapping kunnen doen en kan weer inchecken. Troep is het, allemaal!
[ Voor 48% gewijzigd door CodeCaster op 27-09-2013 12:45 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


