CODEWITHSUNDEEP
version-controlmercurial
antony
antony

Reputation: 2997

Starting to version an already medium size project

I am about to start participating in the development of a medium-sized project (~50k lines) that was until now written by a single person, and not versioned; as a result folders are cluttered with different versions of the same file (named file1, file2, file3, etc.).

I proposed to start using a VCS for it (a priori Mercurial, which is the only one I've ever used -- for my personal projects --, but I'm open to suggestions), so I'm taking any good ideas as to how to "start" the repository. E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed? Or something else?

(constructive remarks on mercurial vs bazaar vs git vs whatever are also welcome.)

Thanks for your tips.

Upvotes: 3

Views: 122

Answers (4)

s.m.
s.m.

Reputation: 8043

I think Mercurial is a good choice. Lightweight, fast, very simple to use and well-integrated with Windows (if that's the platform you're dealing with).

I would probably get rid of all the clutter before the first commit. Delete everything you don't care about, run all the necessary tests and only then do the commit.

Yes, I'm dead set against the 0-day cluttering of repos.

Granted, a 50K SLOC project isn't very big, but if you commit files you already know you won't need, they will make your repo slightly bigger.

Also, remember to check that the tree doesn't contain large binary files. If it does, get rid of them if at all possible.

Upvotes: 1

Chris Walton
Chris Walton

Reputation: 2533

My approach to this was:

  1. create a Mercurial repository in the existing project folder ("existing")
  2. commit all project files to "existing"
  3. create an empty repository in what a different location ("new")
  4. As files are tested and QA'd (this was necessary because there was so much dross in "existing") pull them from "everything" to "new".
  5. Once files had been pulled into "new"; delete the corresponding files from "existing". If access is needed to these files while the migration is under way, push them back from "new" to "existing".

This gave me the advantage of putting everything under some sort of control for recovery purposes, control over introducing the project to the DVCS. Eventually the existing project folder became completely tested and approved for the project moving forward. At this point the "everything" directory could be deleted or changed into a working folder; and "new" became the actual project folder.

Upvotes: 1

Cat Plus Plus
Cat Plus Plus

Reputation: 129894

E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed?

If the size of the repository is not a concern, then yes, that is a good starting point. Otherwise you can just commit what's actually used, and go from there.

As for which system, all DVCSes stick to the same core principles. Which one you pick is entirely subjective — the only way to truly know which one you like is to try each one.

Upvotes: 4

Rob Goodwin
Rob Goodwin

Reputation: 2777

I would say use what you are the most comfortable with and meets your needs. As far as where to start, I personally would seed the repo with the current source as is, that way you can verify that everything builds and runs as expected. you can make this initial seed a branch. That way you can always go back to your starting point before refactoring.

Upvotes: 1

Related Questions