Subversoin best practice
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Subversoin best practice
When do you commit to a repo?
1. Days end
2. Each time you complete a task and a unit test to confirm it works
3. Several days considering how long your tasks take
The reason I ask, is I am considering implementing a SVN repo...and I'm wondering if I could use timestamps between checkout and commit to log the esitmated project time. I suppose if you made atomic/daily commits this might actually be useful, of course if your ocmmits take days before everything is ready to go, then obviously the timestamps would be inaccurate or at least requires acommodating the time during a regular daya which is not spent developing.
What says you?
1. Days end
2. Each time you complete a task and a unit test to confirm it works
3. Several days considering how long your tasks take
The reason I ask, is I am considering implementing a SVN repo...and I'm wondering if I could use timestamps between checkout and commit to log the esitmated project time. I suppose if you made atomic/daily commits this might actually be useful, of course if your ocmmits take days before everything is ready to go, then obviously the timestamps would be inaccurate or at least requires acommodating the time during a regular daya which is not spent developing.
What says you?
Re: Subversoin best practice
I follow:
http://svn.collab.net/repos/svn/trunk/d ... tices.html
http://svn.collab.net/repos/svn/trunk/d ... tices.html
Commit logical changesets
When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a "name" for the change. You can mention this revision number in bug databases, or use it as an argument to svn merge should you want to undo the change or port it to another branch.
Re: Subversoin best practice
I agree with panic, and would also like to add that I try to commit several times a day at least. If I have to roll back since I accidentally lost something or made a mistake, I don't want to roll back several days...
Re: Subversoin best practice
When I was working on my other project, I committed once I added a good number of features, and when I had a stable working version. But I think I like what panic posted better.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Subversoin best practice
Personally I can see that as being a good practice...the more backups you have the better...but I have also heard others swear that only when whatever your working on is functional, should you then commit...I agree with panic, and would also like to add that I try to commit several times a day at least.
Saying either is subjective I suppose...I just think being able to roll back, even to potentially broken code might make sense.
I like the idea of tracking time spent on a project based on timestamps between commit's.
Re: Subversoin best practice
Well it depends - if you are committing to trunk, then preferably only working code. During active development I usually commit only to the dev branch I am on, so it's not a problem.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Subversoin best practice
The way I have my repo(s) setup is somewhat...unconventional...
Basically I have accounts, which are live code and actively used by clients so the code better not break. Then I have development, with sub-branches to test ideas, etc. Where thr trunk of that repo is the base code for all others.
At least this is how I have it organized and planned out in my head...we'll see how well everything works when I apply it to live users, systems, etc.
When I first picked up VC I integrated commit into my save button so essentially I had perpetual, serialized undo...but that defeated the purpose of having 'named revisions' which is also handy, working with dates proved to be more difficult than I expected.
Now I am thinking I will commit at the start of the day (with a simple superficial change and a quick comment about starting for the day) and the end of the day, using a list of TODO comments I've hammered out. This gives me something of an idea as to how much time it took and timesheet tracking as well. The code won't won't always be functional but it will be versioned and comments will let me know what changed. I hope to then dump the comments between versions to have something of an automatic change log or history.
Again, we'll see what happens
Basically I have accounts, which are live code and actively used by clients so the code better not break. Then I have development, with sub-branches to test ideas, etc. Where thr trunk of that repo is the base code for all others.
At least this is how I have it organized and planned out in my head...we'll see how well everything works when I apply it to live users, systems, etc.
When I first picked up VC I integrated commit into my save button so essentially I had perpetual, serialized undo...but that defeated the purpose of having 'named revisions' which is also handy, working with dates proved to be more difficult than I expected.
Now I am thinking I will commit at the start of the day (with a simple superficial change and a quick comment about starting for the day) and the end of the day, using a list of TODO comments I've hammered out. This gives me something of an idea as to how much time it took and timesheet tracking as well. The code won't won't always be functional but it will be versioned and comments will let me know what changed. I hope to then dump the comments between versions to have something of an automatic change log or history.
Again, we'll see what happens
Re: Subversoin best practice
At any time I've achieved an acceptance criteria for the story I am working on, I commit.
We also commit directly to trunk, dev branches are not desirable.
We also commit directly to trunk, dev branches are not desirable.
Re: Subversoin best practice
I commit only bug fixes / minor updates to the trunk (since it has to be working at all times). Significant features I work on in the branches and merge to the trunk when they are stable. I believe this is standard practice.
Re: Subversoin best practice
I love standards. There are so many to choose from.
Why leave it for a bulk merge? Why not commit, and thus merge, immediately?
You have tests to verify it is "stable" (another term I have a pet-hate for.)
It is new functionality that is requested.
Delaying the merge will only increase the time gap to allow possible collisions with other work that is ongoing.
It can only increase the amount of work that will be required if there is a collision.
It adds extra headache when planning who will be working on what. If everyone works from Trunk, you'll not have that woe because everyone will be committing/updating often and thus collisions will be minimal and resolved quickly.
A branch is nothing but an extended working copy. It defeats the objective of committing often entirely when using a branch, because those changes won't see trunk until the entire branch is finished. You'd might as well just leave all the changes in your working copy..
There is also another practice that I sometimes use. The first thing I'll do in the morning when I arrive at the office is revert my working copy. Why? Anything I didn't commit before going home is old-hat. Trunk is the latest and greatest. If I had something to contribute, I should have committed it the moment it was ready, not left it in my working copy.
Why leave it for a bulk merge? Why not commit, and thus merge, immediately?
You have tests to verify it is "stable" (another term I have a pet-hate for.)
It is new functionality that is requested.
Delaying the merge will only increase the time gap to allow possible collisions with other work that is ongoing.
It can only increase the amount of work that will be required if there is a collision.
It adds extra headache when planning who will be working on what. If everyone works from Trunk, you'll not have that woe because everyone will be committing/updating often and thus collisions will be minimal and resolved quickly.
A branch is nothing but an extended working copy. It defeats the objective of committing often entirely when using a branch, because those changes won't see trunk until the entire branch is finished. You'd might as well just leave all the changes in your working copy..
There is also another practice that I sometimes use. The first thing I'll do in the morning when I arrive at the office is revert my working copy. Why? Anything I didn't commit before going home is old-hat. Trunk is the latest and greatest. If I had something to contribute, I should have committed it the moment it was ready, not left it in my working copy.
Last edited by Jenk on Tue Dec 02, 2008 5:33 am, edited 1 time in total.
Re: Subversoin best practice
Because until completion, new features break the current build. Until they are stable, I can't deploy the trunk to production - you can't roll uncompleted features to production. The trunk is used to continuously integrate bug-fixes and small modifications so it must be working at all times.
I am talking about a project that is already deployed of course. During local development there is no reason not to commit to the trunk all the time.
I am talking about a project that is already deployed of course. During local development there is no reason not to commit to the trunk all the time.
Re: Subversoin best practice
See my edit, particularly regarding tests, and also... If they break anything, they are not worthy of addition and should not be committed. Period. "New Features" are not new features if they break anything that already exists. They are broken code.
I too, am talking about applications that are already deployed. Infact, I'm talking about any and all source controlled systems. (As an example, we source control an entire Linux image.)
For deployment, we don't deploy from trunk - we copy from trunk, to a release branch. These release branches are read only, and have a release number. Now anyone wanting version 'x' will be able to get version 'x' and it will be an identical version 'x'. Anything deployed from trunk will be old the moment anyone commits anything, which is usually within minutes.
I too, am talking about applications that are already deployed. Infact, I'm talking about any and all source controlled systems. (As an example, we source control an entire Linux image.)
For deployment, we don't deploy from trunk - we copy from trunk, to a release branch. These release branches are read only, and have a release number. Now anyone wanting version 'x' will be able to get version 'x' and it will be an identical version 'x'. Anything deployed from trunk will be old the moment anyone commits anything, which is usually within minutes.
Re: Subversoin best practice
When I say they break the trunk - I mean there are features that are not working yet. You can't deploy a feature that does nothing or is half baked, into production.
If your "releases" as you call them are read-only, how do you release quick bug-fixes or small modifications?
If your "releases" as you call them are read-only, how do you release quick bug-fixes or small modifications?
Re: Subversoin best practice
by creating new releases (and thus incurring a new version)
"Versions" are nothing more than arbitrary incremental number that we can use to identify a snapshot of trunk.
"Versions" are nothing more than arbitrary incremental number that we can use to identify a snapshot of trunk.
Re: Subversoin best practice
So what you are saying you use the trunk for active development and a branch for deployment? that's the same thing I'm doing only with different semantics...