@conference {971,
	title = {Branching and merging in the repository},
	booktitle = {the 2008 international workshopProceedings of the 2008 international workshop on Mining software repositories  - MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {19-22},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {Two of the most complex operations version control software allows a user to perform are branching and merging. Branching provides the user the ability to create a copy of the source code to allow changes to be stored in version control but outside of the trunk. Merging provides the user the ability to copy changes from a branch to the trunk. Performing a merge can be a tedious operation and one that may be error prone. In this paper, we compare file revisions found on branches with those found on the trunk to determine when a change that is applied to a branch is moved to the trunk. This will allow us to study how developers use merges and to determine if merges are in fact more error prone than other commits.},
	keywords = {argouml, changes, cvs2svn, diffj, revision, scm, source code, version control},
	isbn = {9781605580241},
	doi = {10.1145/1370750.1370754},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p19-williams.pdf},
	author = {Spacco, Jamie and Williams, Chadd C.}
}
@conference {1004,
	title = {Release Pattern Discovery via Partitioning: Methodology and Case Study},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {19 - 19},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {The development of Open Source systems produces a variety of software artifacts such as source code, version control records, bug reports, and email discussions. Since the development is distributed across different tool environments and developer practices, any analysis of project behavior must be inferred from whatever common artifacts happen to be available. In this paper, we propose an approach to characterizing a project{\textquoteright}s behavior around the time of major and minor releases; we do this by partitioning the observed activities, such as artifact check-ins, around the dates of major and minor releases, and then look for recognizable patterns. We validate this approach by means of a case study on the MySQL database system; in this case study, we found patterns which suggested MySQL was behaving consistently within itself. These patterns included testing and documenting that took place more before a release than after and that the rate of source code changes dipped around release time.},
	keywords = {bitkeeper, bt2csv, cvs, evolution, mysql, releases, revision history, scm, softchange, version control},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.28},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300019.pdf},
	author = {Hindle, Abram and Godfrey, Michael W. and Holt, Richard C.}
}
