Torben, and any who are new to Git,
The account + 1st repository setup instructions at GitHub.com are
great when followed with a review of the well-diagramed ProGit.org
Cheers,
Zak
On Dec 10, 2010, at 2:08 PM, Torben Weis wrote:
Hi,
sorry, I misunderstood your idea. As long as we do it one after the
other
that's fine.
We should definitely voice a time line for the move. Furthermore, we
should
put up some instructions
of what to do with development clones that could not be committed
before the
move.
I am not a hg/git wiz and would be in some trouble when the project
moves
before I can commit my changes for code review.
Once we know how to migrate development clones to the new
infrastructure
"easily" we define a "move day".
This will lead to a freeze while development can continue on the
clones.
If the system is stable at move day (i.e. compiles, starts and does
not
crash immediately), we move.
If it is broken we try the next day. This way we can be sure to move a
stable source tree.
Greetings
Torben
2010/12/10 Michael MacFadden <[email protected]>
Torben,
I agree that moving infrastructure and code clean up could be risky
to do
at the same time. That is exactly why I am recommending doing it
now. I
suspect that we won't be ready to move the code over for several
weeks to a
month or two. We don't have committer accounts, issue tracking,
source
control, etc. It might take some time to get all that in the place.
We can use that time to get the code base cleaned up before the
move. As
it is, people are already committing lots of code and functional
changes
right now. I don't see how removing dead code that is not being
used is any
more risky.
On that note though, we may want to start thinking about the time
line for
the move and whether we want to have a code freeze during that time.
~Michael
On Dec 10, 2010, at 12:29 PM, Santiago Gala wrote:
It can be done in a branch or patch to be applied later. Not sure
about
hg,
very easy with GIT.
Regards,
Santiago
El 10/12/2010 20:57, "Torben Weis" <[email protected]> escribió:
Hi Michael,
I try to avoid changing code and infrastructure at the same time.
It is
tempting to start with a clean code base on a new infrastructure,
but
there
is a risk that in the end it takes
a) too long because of unforeseen issues
b) if something breaks, it is difficult to see what caused the
problem.
I am all in for a code cleanup. I am just not sure that doing it
together
with the source code move is the best timing.
Greetings
Torben
2010/12/10 Michael MacFadden <[email protected]>
All,
As we ponder moving our source code over to Apache in the next
month or
two, I thought this would be a great opportunity for us to have
a code
clean
up drive. Looking through the code base it is apparent that we
have
some
code atrophy. As we have re-organized, rewritten, or replaced
functionality, in many cases the former code has been left in
the code
base.
Dead code is a threat to the code based since it a) has to be
maintained,
b) has the potential to break, c) confuses new developers. I
suggest
that
we take this opportunity to look at the areas of code we work
with and
remove any legacy code that is no longer needed. Of course I would
suggest
checking with others before just removing large bits of code,
that you
yourself didn't write.
Thanks,
Michael
--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
[email protected]
--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
[email protected]
