Anybody still here ?

[Lars Segerlund]

  So I don't understand, have I dropped off or am I dead ? Just kidding 
the list obviously still a bit active.

  I have been looking at arch, darchs and both are very nice, but for 
one, they totally clobber my working copies and so on ... they are not 
just 'done yet' :-) ( sorry about the aggravation this might cause ), IMHO.

  What I am talking about here is keeping track of the patches ( perhaps 
from multiple sources/developers ), enabling them all to import their 
patches into the repository against a given revision, and using this 
information ( presenting it in a good form to the developer ) in order 
to minimize the pain of bringing 'old' ie. patches that didn't make a 
given revision ( where revision is the process of deciding what goes 
into the new one, not automaticly include al commits as in cvs ).

  But I might consider pestering the arch mailing list instead ;-) since 
I know I have a lot to learn about changesets/patchsets and merging ( 
the three way merge still gives me some trouble ).

  Arch has a lot of what is needed for the handling of the 
changes/merges and so on, but I feel that it still lacks a lot to take 
on fx. bitkeeper, ( which would be nice to get rid of for kernel 
developement IMHO ). On the other hand subversion is a very nice cvs 
replacement, but I fear that it cannot, ( or there is little interest of 
), do the most modern features of revision control and so on.

  I am using subversion inhouse, and it works great, but if you look at 
the process of submitting patches to fx. gcc by mail, and web and how 
they are integrated I feel that this is something to target, since the 
main thing bitkeeper actually does is enabling a disordered bunch of 
programmers to do developement at the same time :-) ..

  Perhaps I should give an axample of a thought up session to illustrate ?

  / regards, Lars Segerlund.


Tom Lord wrote:
>     > From: Lars Segerlund <lars.segerlund at comsys.se>
> 
> 
>     >   Is this list dead or have I dropped of ?
> 
> Are those the only two choices?
> 
> 
>     >   I had a little thought about the handling of changesets and 
>     > revisions/merges, the thought was that if the repository keeps track of 
>     > patches ( in the meaning of a complete changeset/patchset ) instead of 
>     > revisions, doesnt everything get much more simple then ?
> 
>     >   That would mean that for a given revision with a number of patches ( 
>     > perhaps pending ? ) anybody could check out the revision with the 
>     > desired patch ? This would also make it possible to migrate 
>     > nonconflicting patches to new revisions, and in this way you don't get 
>     > left trying to catch up to the main revision if you have a big patch for 
>     > a given software.
> 
>     >   So, my question should not the patches be handled by the repository, 
>     > and the creation of new revisions of the patch manager for that repository ?
> 
> 
> Your idea is a little vague, at least the way it's expressed.
> 
> I _think_ you're saying something like "I want a revision to be defined
> as a set of nonconflicting patches -- that way, I can define a
> revision out of thin air as `that other revision, plus these patches'
> (a set union of patches)".  Is that about right?
> 
> Well, "yes; er ... no; er ... maybe."
> 
> Come over to arch-users.  That's not too far from how arch actually
> works and we can set you straight on the delta from here to there.
> The (perhaps surprisingly) problematic part of your idea is the word
> "nonconflicting" and its implications.  Your intuition about how
> patches work is seemingly misleading you there.  But anyway, this is
> more a revision control idea than a changesets idea.
> 
> The Darcs guy might having something to say about this idea too, but,
> if you give us a chance on arch-users, we can explain why he's wrong
> :-)
> 
> -t
> 
> 
> (That'd be: http://lists.fifthvision.net/mailman/listinfo/arch-users/)
> 
>