• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

What are the best practices on mainline (trunk) code management?

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When a new project begins, source codes are checked into mainline first.
Then the mainline is branched when/before the product is released to allow parallel development, etc.
Let's say I branched into v1.0.
And let's say the upcoming new features are so vastly different than v1.0 that a lot of 'new' files are to be checked into mainline, as well as a lot of pre-existing files are no longer relevant.
What is the correct way to handle the mainline regarding these non-relevant files ?

1) Remove (delete) them from mainline. Of course it leaves the deletion history so that we can go back to them, but as far as the HEAD revision goes, they will no longer be visible. With each releases (v2.0, v3.0), the mainline is kept clean. But there are a lot of deletions going on in mainline with each release. And we won't be able to mix old (deleted) files with latest files when a need arises in the future in order to produce a certain feature.

2) Just leave the non-relevant files. When it's time to branch again (v2.0), select only those relevant files to branch, so that this branch will not be polluted with irrelevant files. Let's say the next set of features are (again) so vastly different that a lot of files become irrelevant, then the irrelevant files will keep growing through each releases (v2.0, v3.0), but at least with each release we take care to branch right set of files and we are not deleting files from mainline. So, latest files can work with old files to produce a new feature as needed.

This situation (vastly different features) may sound unrealistic, but imagine that a product starts with client/server, and then later decides to replace a thick client with HTML. Another example is replacing flat file database with relational database. With 1), we can't mix deleted files with latest development code. In other words, if I am developing a new feature and it needs a thick client (which is now deleted), the mainline can only check out old revision or new, not both at the same time. With 2), a lot of files in mainline will become irrelevant over time, while allowing reuse of old-revision files when needed.

What would you choose - 1), 2)? Any other ideas?
 
Saloon Keeper
Posts: 28492
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exact practices vary depending on the VCS in use. Since you used the term "trunk", I'll use SVN as a model.

In Subversion, it's good practice, though not required, to keep 3 folders at the root of the project archive: trunk, branches, and tags. The trunk is the mainline and is normally the official "production" code archive.

When it's desirable to "go out on a limb", you can copy the trunk into a new folder under the branch directory and check stuff in and out of there as you work on the project. Once it's ready for "prime time", you merge the results of the branch mods back to the trunk. On a large project, more than one person can be working on more than one branch.

A VCS is not like a filesystem. You shouldn't be deleting objects. In fact, you cannot delete objects. All you can do is create a newer version that doesn't contain those objects. The backtrail of the project retains all the previous generations of those objects. This is, in fact, one of the key tenets of a good VCS. Nothing is ever lost. Like a good accounting system, you can countermand a transaction, but both the original transaction and it's negation remain as part of the permanent record. And deleting doesn't free up anything, so it's pointless in any case.

Subversion, in fact, is extremely efficient when doing copy operations. Although to the end user, copying a project from a trunk to a branch or tag looks like it's duplicating a lot of data, internally Subversion knows better and only records actual differences.
 
What do you have in that there bucket? It wouldn't be a tiny ad by any chance ...
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic