Soll ich den alten Stamm eines neu geschriebenen Projekts "in Rente gehen"?

Question

Kürzlich habe ich ein altes Projekt, an dem ich vor etwa zwei Jahren gearbeitet habe, noch einmal besucht. Offensichtlich habe ich während dieser Zeit neue Gewohnheiten gelernt, wie man am besten programmiert, und ich habe das Problem, die Tests zu behalten, die Implementierung zu verwerfen und das gesamte Projekt neu zu implementieren. Es ist kein großes Projekt, und ich glaube, ich werde nicht viel verlieren, wenn ich es neu schreibe.

Allerdings weiß ich nicht, was ich mit der Versionsgeschichte tun soll. Es ist wahrscheinlich, dass die neue Version nach der Aktualisierung nur 3-4% ihres Codes mit der alten Version teilen wird. Darüber hinaus sind die Veränderungen in der Regel so weitreichend, dass der Versuch, saubere Changesets beizubehalten, eine Übung in Frustration und Zwecklosigkeit ist. Angesichts dieser Tatsache scheint es unnötig zu sein, potentielle Entwickler dazu zu zwingen, die alten irrelevanten Versionen herunterzuladen.

Eine Option, die ich in Erwägung gezogen habe, ist, den Stamm in einen Zweig zu verschieben, etwa old-trunk/, und mit der Entwicklung in einem leeren Zweig zu beginnen. Ich weiß nicht, ob das eine gute Idee ist, und ich bin besorgt, dass zwei Stämme zu Verwirrung führen könnten. Was bringt mich zu der Frage:

Was denkt SO? Wenn Sie auf ein Projekt gestoßen sind, das seinen Stamm "zurückgesetzt" hat, würden Sie dadurch verwirrt sein?

Answer 1

Warum beschriften/markieren Sie den Stamm nicht einfach mit "OldVersion" und setzen die Entwicklung am selben Ort fort? Auf diese Weise meiden Sie den doppelten Zweig und behalten immer noch Wege bei, um zur alten Version Ihres Codes zu gelangen. Wenn Sie kein anderes Produkt entwickeln, möchten Sie wahrscheinlich den gleichen Stamm behalten.

Answer 2

Ich Tag die $ Stamm, so gibt es eine "Kopie". Markieren Sie die zuletzt veröffentlichte Version, oder das Datum, bevor Sie wieder damit begonnen haben, usw. Ich markiere tatsächlich das veröffentlichte Datum und benenne meine Tags mit dem eigentlichen Datum. (Verwenden Sie Label inplace of tag, falls dies von Ihrem System unterstützt wird).

Nachdem es markiert ist, löschen/umbenennen/überholen nach Bedarf. Die Versionsgeschichte ist da, nur für den Fall. Und Sie haben eine vollständige Kopie, die zu Archivierungszwecken mit/gekennzeichnet ist.

Answer 3

Angenommen, Sie verwenden SVN, es gibt wirklich nichts extra zu tun. Denken Sie nur an die Revision, von der Sie mit dem Refactoring begonnen haben, und arbeiten Sie dann weiter am Stamm. Es ist besser, als auf einen leeren Zweig zu gehen, da die Geschichte der Änderungen von dem alten Code zu einem neuen aufgezeichnet wird.

Wenn Sie jedoch planen, das Ding von Grund auf neu zu schreiben und nur ein paar Bits alten Codes zu kopieren, sollten Sie vielleicht darüber nachdenken, es in einem neuen Repository zu starten.

Answer 4

Ich sehe nicht die Notwendigkeit, die alte Version wegwerfen. Nehmen Sie alle Änderungen vor und checken Sie ein. Neue Entwickler müssen keinen alten Code herunterladen, sie werden immer nur die neue Version ausprobieren.

Answer 5

Nein, es würde mich nicht verwirren, weil die Projektdokumentation das zeigen würde, bevor ich überhaupt hineingeraten wäre. Wir alle haben Mist, der erneuert werden muss und ehrlich gesagt sein sollte.

Sagen Sie jeder, es ist unsicher und nicht HIPAA konform und sie werden Ihnen erneut Code lassen; o) Und dann starten Sie das Futter auf The Daily WTF für den Rest von uns 80))