[Monotone-devel] hiding history, was Re: monotone evaluation in commercial project [long]

[Emile Snyder]

In considering how I might try to go about accomplishing this use case
(want messy local branch that doesn't get sent back out with cleaned up
version) with monotone as it is now, I came to the following work flow:

customer has monotone db accessible via netsync at customer.com,
collection "project"

developer creates local db dev.db, does 'monotone --db=dev.db pull
customer.com project'

developer copies dev.db to mess.dev.db

checks out project from mess.dev.db,  (starting revision REV0)
does 
messy change 1 -> commit --branch=mess
messy change 2 -> commit (on mess)
messy change 3 -> commit (on mess)
clean up -> commit (on mess)
propogate mess -> project (resulting rev is REVC1)
messy change 4 -> commit (on mess)
messy change 5 -> commit (on mess)
clean up -> commit (on mess)
propogate mess -> project (resulting rev is REVC2)

ok, done with messy stuff, we now want to get branch 'project' from
mess.dev.db to our dev.db without also getting branch 'mess'.

so, 
monotone diff REV0  REVC1 > cleanpatch.01
monotone diff REVC2 REVC1 > cleanpatch.02

now,
checkout 'project' from dev.db, cd into working dir
patch < cleanpatch.01
commit
patch < cleanpatch.02
commit
monotone push customer.com project

Does that look right?  If that is the work flow that people are
imagining, it seems to me that you could support it a little by
providing 'monotone export_branch' (either built in, or as a script
using monotone automate commands?) to generate branch.XX diff files from
a branch in a repository.  (You want the branch to look like a straight
shot development line of A -> B -> C... etc., so you would have to
collapse regions of the branch where you have forks+merges by diffing
the fork point and the first point where the branch comes back to a
single line.)

I can also imagine a command (again, either built in or just an
automated script using monotone) to take an ordered set of patch files,
an initial revision you want to start applying them to and a target
database, which would handle the checkout + patch/commit cycle.

If it was desired by lots of people and deemed useful functionality it
seems like this could be further compressed to a new 'monotone
push_branch' command which would do the equivalent of those two actions.

-emile

On Thu, 2005-04-14 at 08:23, Peter Simons wrote:
> Richard Levitte writes:
> 
>  >> Is being able to get at this history really so bad a thing?
> 
>  > Maybe there is source of embarassment in it?  :-)
> 
> That's a good reason. ;-)
> 
> Another one is that not all projects are free software, and
> not every part of every software is necessarily meant to be
> available to everyone. The ability to split a large package
> into components (branches) which can exist in various
> versions (repositories) and which are kept in sync through
> "propagate" is very important to many applications.
> 
> Monotone's principal architecture is perfect for dealing
> with this setup. The requirement that every repository has
> to have the entire ancestry graph, however, doesn't fit
> this use pattern very well.
> 
> Peter
> 
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

+----------------------------------------------------------------------
AAAAAA - American Association Against Acronym Abuse Anonymous. 
+----------------------------------------------------------------------