Guten Tag Johan Corveleyn,
am Montag, 13. Dezember 2010 um 21:04 schrieben Sie:
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it "probable" that
> they will need to take another look at them sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision was
> in which the project still existed).
I personally totally agree with that and wouldn't delete the projects
either, unless pretty sure it's uninteresting.
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be resurrected, it can
> be easily copied from that tag.
> Thoughts? Other ideas? Pros and cons?
In my mind it really depends on the directory structure in the
repository one uses. If you just have trunk/project 1 to n an for
example no tags|branches/project 1 to n I would create an
archive|obsolote|eol|whatever folder in tags and move each project
with eol in there. If you have tags|branches/project 1 to n I would
prefer keeping the TTB-structure as is and create, as you suggested,
a new root folder archive|... and recreate the TTB-structure for each
project in there. Depending on your development environment using the
same directory structure you already work with, just in a different
level, may help you in running, building or whatever your old
projects, if wanted. If it's more interesting to see which projects
are out of life in the first way, a new root directory with project
specific sub directory with TTB in there could be an alternative. I
would decide regarding my development environment.
Mit freundlichen Grüßen,
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Received on 2010-12-14 08:57:16 CET