team_tools/README at main · Ensembl/team_tools · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
WARNING: This repository and its contents are now deprecated and are only kept for reference

The plan as I imagine it...


Files on master branch
======================

 bin/	 	things we all want on our $PATH, by some consensus?  Not sure about this.

 t/		tests that can safely be run with no setup or side-effects

 $project/	small, mostly self-contained projects.
		Should each contain a README ?
		If they got bigger they might warrant splitting into another repo.


Files on branches named $dev/$foo
=================================

$dev = username of developer; the owner of that branch.

$foo = name of some sub-project.  Possibly matching the directory name
$project/ .


mca suggests this form of ownership so that commits on such branches
may be "owned" but still visible to team members (without an N-squared
pulling of commits from other people's working copy repos).

These owned branches may be amended/rebased, at any time until they
are merged to master, even after pushing to intcvs1.

If these branches use the filenames pattern above they will merge to
master easily, but naming the branch after a developer suggests the
content is not ready for sharing.


Wanted
======

Neat and clean way to make cross-project dependencies.  Without
crosslinking everything into a bucket of code.