[darcs-users] Fwd: Darcs Problems

[James Sleeman]

Stephen J. Turnbull wrote:
> Suppose it could be done automagically (eg, every time you save), and
> the small "autocommits" hidden in the normal history report?  (Eg, the
>
An interesting idea.


> If you're doing that consistently, I suspect it's going to be
> difficult to "fix" Darcs (or any other VCS) to automatically do what
> you want well.
>
Yes I recognise that automation there is impossible, hence why I want a 
darcs supported way to do it manually...


>  > there is no way to say "hey Darcs, I want that, but not that,
>  > let me sort out any problems (conflicts) that causes"
>
> Sure there is.  diff | patch will work just as well as it always did.
> Of course, that doesn't help you the second time you want to do the
> same thing.
>
...very much like this but with Darcs knowing that my "new" patch made 
with the classical diff|patch and then recorded is equivalent in some 
regard to the existing patch in that other branch.

I indeed have resorted to using diff|patch, and wrote a script to help a 
bit with doing it.  But with darcs not knowing about the "equivalence", 
I wind up using more classical diff|patch than darcs push/pull :-(


> It sounds to me like your requirements are quite close to Mercurial's
> "queues" extension.
Queues would be one potential way to help, essentially always keeping 
your "local changes" as a queue of separate sort-of-patches on the top 
layer of the patches, nothing can depend on them that way.
I think this is the same way in which one would think that rebase would 
be helpful (and rebase may be a better solution, given an appropriate 
interface/tool to manage it), pulling your local patches always "to the 
top" before pushing/pulling the others.
I hope one day to see rebase in darcs officially, until then I can't 
experiment with that :-(


> (I'm looking for a specification the Darcs devs can follow, not suggesting
> you switch VCSes.)
>

To be clear, I'm still only using Darcs for 4 related websites which are 
not related (don't share code) to my hundreds of others.

My primary VCS is SVN where my hundreds of sites which share code are. 
And I handle my requirements by way of svnmerge.

Simplifying somewhat this is how it works in svn (been doing this way 
for 5-6 years);

/trunk
/siteX
/siteY
...

siteX begins as a copy of trunk.
I develop siteX
I use svn's merging (via svnmerge tool) to selectively merge or block 
the new changesets in siteX up into trunk.
svn remembers (by way of attributes) which changesets have been merged, 
and which are blocked
At some time in the future I update siteX by merging down the new 
changsets in trunk

Basically, svn has no concept of dependencies, so you can imagine this 
process is just like if darcs had an --ignore-dependencies switch to 
pull/push

The "cherrypicking" ability of darcs I thought would be a far better way 
of doing this, and give all the other darcs benefits (of which there are 
many).  But in reality, as described, the enforced requirement of darcs 
to take all dependencies, makes it practically impossible from within 
the darcs ecosystem (in my experience).


> In the context of Darcs, it might be useful to have a semi-automatic
> UI that would display the primitive patches that create dependencies,
> and allow you to split the containing patch.  I'm not sure how useful
> this would be for you given you prefer larger patches.
If darcs could even simply say why the (implicit) dependancy exists... I 
think that would be a useful feature (one could always unrecord and then 
record separate patches based on that information).  A semi automated 
means to split that depended upon patch so those "reasons" were collated 
into their own patch, even more so.


---
James Sleeman