Configuration Management question (Subversion)

[defenseman]

I've posted this under Data Storage but I would like to people's opinions from this sub-forum as well...

Say a project has only two files (to keep things simple):
1. code.c
2. design.pdf

Project lifestyle:
1. Make a new base repository
2. Users checkout, modify, merge, commit
3. More users checkout, modify, merge, commit
4. One branch is made (aka Alpha), another branch his made (aka Bravo)
5. Users under the Alpha configuration need the code and design to look a specific way. Users checkout, modify, merge, commit under their branch.
6. Users under the Bravo configuration need the code and design to look a specific way. Users checkout, modify, merge, commit under their branch.

Problem...
7. Users under Alpha or Bravo find some bugs in the base code and/or design, but Alpha and Bravo can't exactly merge because their specific configurations will always be different.

How does Subversion handle this problem? Because the Alpha and Bravo guys have different configurations, they can merge code, but constantly have to ignore certain changes. Furthermore, they can't really merge the design since the design is in PDF format.

How should I handle this scenario?

 

[Sgarissta]

Binaries are "difficult" to deal with in most SCM systems. Merging them is basically impossible in most systems. The way I deal with this sort of issue (but I use darcs, so I'm not sure exactly how SVN will handle this):

create branch to fix bug.
apply fix to trunk.
update Alpha and Bravo from patched trunk.

Of course if the "bug" is in the binary PDF, then you're pretty much hosed. The typical solution for handling binary files, is whenever possible not to. Meaning, if the binary is generated by something, record changes to the original source, not the resulting binary.

 

[nameless_centurian]

if this situation happens, i think you miss the entire point of version control. where are your software architects? they didn't see this coming?

 

[defenseman]

if this situation happens, i think you miss the entire point of version control. where are your software architects? they didn't see this coming?

I hear ya... So heres my latest thoughts:

For software, you must design software so it can have configurations.

For hardware, you must forfeit branching techniques. If you really want a branch configuration, your going to have to manually copy over fixes to each configuration. A trunk+branch technique for hardware design can only exist if the design software supports it. What I didn't realize at first is how Subversion stores binary files. Until I actually tried different file types, I didn't realize how it supported it.

So my personal solution is to have multiple repositories under a project folder on a network share.

./ProjectA
./ProjectA_Hardware_Design (repository)
./ProectA_Software_Design (repository)

Users who work on either the hardware or software must follow the "Checkout -> Modify -> Merge -> Commit" technique or the "Merge -> Modify -> Merge -> Commit" technique.

 

[ambientZ]

you might want to consider moving the 'base code and design' out to a separate module that both alpha & bravo make use of.

 

[devman]

Un-mergable files, such as images or anything that can't be line for line merged, should be locked when checked out and unlocked when committed to prevent wasted work effort. If by different configurations you mean different supporting libraries or project metadata (environment setup, arguments, etc) those should be un versioned and not tracked by SVN.