Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Tue, 28 Feb 2012 18:03:55 -0500 Christopher Berardi cbera...@natoufa.com wrote: Why not just use your shell's aliasing mechanism? For example, in a Bourne compatible shell you could place this in your .shrc file: alias cip='fossil ci --private' You're right. It's possible to do it via shell's alias mechanism (I use zsh), but, as others replied, it's not convenient for non-Unix users and aliases are somehow part of today's modern DVCS-es. However, ability to select single branches for push/pull and rollback are standing much higher on my desired list for Fossil. Sincerely, Gour -- One who is not connected with the Supreme can have neither transcendental intelligence nor a steady mind, without which there is no possibility of peace. And how can there be any happiness without peace? http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assign ticket to file(s) or abusing Fossil a bit
On Tue, 28 Feb 2012 15:19:37 -0500 Ron Wilson ronw.m...@gmail.com wrote: I am reasonably sure it can be done with out C surgery. (However, a proper search feature for tickets should be added to Fossil.) This sounds good. ;) Use Fossil wiki pages for the master patient files. (the built in wiki pages). Isn't it mentioned that all Fossil's docs is moved to 'embedded' docs? In a Fossil wiki page, a ticket id enclosed between [ and ] will function as a link to the ticket. (This also works with embedded document wiki pages, but updating embedded document pages with the Fossil UI is not (yet) possible.) Is this the reason why you suggest 'built-in' pages? Using some combination of TH1 and Javascript, the link to a new ticket can be appended to a wiki, automatically, when the ticket is created.Actually, this would be done in View Ticket right after the ticket is forst entered. At that point, the ticket status is New. At that point, Fossil performs an automatic View Ticket. This is where the extra processing takes place. A combination of TH1 and Javascript would see that the status is New and display a Confirm button, along with a message instructing the user to verify the entered information, then clinck on Confirm. Javascript would then subimt both a HTTP request to append [ticketID] to the patient's wiki page, and a HTTP request to update the ticket status to something other than New. (probably necessary for the View Ticket of a New ticket to include the raw wiki page content in a hidden text area that the Javascript would then append to and submit much like editing a wiki in the Fossil UI.) Thank you very much for your suggestion, although I've to think a bit how to implement it. Sincerely, Gour -- The spirit soul bewildered by the influence of false ego thinks himself the doer of activities that are in actuality carried out by the three modes of material nature. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Tue, Feb 28, 2012 at 07:28, Richard Hipp d...@sqlite.org wrote: Assuming we go with Fossil 2.0, can somebody propose a list of interface changes that are needed. We don't want to repeat this exercise if it can be avoided, so let's fix everything all at once. Here's a start: (1) fossil rm removes the files from the disk (2) fossil mv renames the files on disk (n+1) Ability to reference commit parents ala GIT: trunk^ is a main (non-merge) parent of the trunk; trunk^^ is parent-of-parent-of-trunk and so on. I am tired of cutting/pasting SHA1 hashes from web-gui to command-line and back. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
Leo, did you know you can type 'fossil time' from the cmd line to get the last 10 commits? then just use the first 3-6 characters to reference the correct parent, that way avoiding the command line. I'm not saying that it solves the 'single command' problem, but it sure beats launching the ui sometimes. Tomek On Wed, Feb 29, 2012 at 12:49 PM, Leo Razoumov slonik...@gmail.com wrote: On Tue, Feb 28, 2012 at 07:28, Richard Hipp d...@sqlite.org wrote: Assuming we go with Fossil 2.0, can somebody propose a list of interface changes that are needed. We don't want to repeat this exercise if it can be avoided, so let's fix everything all at once. Here's a start: (1) fossil rm removes the files from the disk (2) fossil mv renames the files on disk (n+1) Ability to reference commit parents ala GIT: trunk^ is a main (non-merge) parent of the trunk; trunk^^ is parent-of-parent-of-trunk and so on. I am tired of cutting/pasting SHA1 hashes from web-gui to command-line and back. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Tags in web interface vs. fossil tag list
On Tue, Feb 28, 2012 at 11:34 PM, Nolan Darilek no...@thewordnerd.infowrote: On 02/28/2012 03:36 PM, Stephan Beal wrote: Amen. Maybe the JSON API should just support a dumbed-down tags interface? So it seems like the command line/web interface would have to use a similar tag filter function, right? I mean, they're filtering out these various tkt/wiki-/event- tags, and presumably others besides. Maybe if everything followed the same code path, we'd be golden? The presumption of the same code paths is fair but unfortunately not the case. The various CLI-vs-HTML-vs-JSON forms of various commands share ashamingly little code. The command-specific logic and ad-hoc data structures (in the form of queries) are normally quite interwoven together. When i started the JSON API it quickly became apparent that it would be too unwieldy and intrusive to interweave the JSON API's logic with the existing HTML/CLI modes, and ended up copying more than a small number of queries from the main implementations. In some cases it has been possible/feasible to factor out shared code for certain routines, but in many cases that hasn't been feasible. (This split/code dupe helps ensure, however, that HTML/CLI/JSON interfaces can evolve independently of each other.) Then all other interfaces be they command line or JSON could require that you opt into whatever other tag types you'd like. The current JSON impl is based on the parameters available to the HTML interface, though often renamed to something more JSON-conventional. i like what Ron suggests: On Wed, Feb 29, 2012 at 12:33 AM, Ron Wilson ronw.m...@gmail.com wrote: On Tue, Feb 28, 2012 at 5:34 PM, Nolan Darilek no...@thewordnerd.info wrote: followed the same code path, we'd be golden? Then all other interfaces be they command line or JSON could require that you opt into whatever other tag types you'd like. This makes a lot of sense. Not automatically give everything, but do allow asking for more. And i'll certainly give that consideration. i'm all ears if you guys have concrete ideas on how the interface should look like. For simplicity, just model your ideas like CLI args (these tend to map easily to HTTP-mode equivalents), e.g.: fossil json tag list -t -w ... -t = include tickets -w = include wiki Should there be a separate command for fetching full key/value pairs (which changes the response structure), or should that simply be an option of the 'list' command (e.g. --verbose)? What should happen if no options are provided - what tags are returned in such a case (or is it an error)? i don't personally use tags all that much, so i could really use suggestions from those who make have use of (or can envision interesting use cases for) tags. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 13:00, Tomek Kott tkott.s...@gmail.com wrote: Leo, did you know you can type 'fossil time' from the cmd line to get the last 10 commits? then just use the first 3-6 characters to reference the correct parent, that way avoiding the command line. How can I do it in a script? Referencing a parent is a fundamental DAG operation and it is missing from fossil 1.x. I hope fossil 2.0 will have something to address it. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] assign ticket to file(s) or abusing Fossil a bit
On Wed, Feb 29, 2012 at 9:35 AM, Gour g...@atmarama.net wrote: Wiki pages can be created/edited via the JSON interface. Ticket handling is still on the TODO list. Where can I find some more docs about that 'JSON' branch which happened 'in the meantime' and before my revived interest to exclusively use Fossil for all our projects. For the time being the docs are in Google Docs (as opposed to fossil embedded docs), available here: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit (Contributors are welcome: send me your gmail address and i can add you to the editor list.) They're currently 48 pages, which will make restructuring and wiki-fying them for inclusion into the main repo's embedded docs (or a separate doc repo) a rather large task. :/ If you've got questions or suggestions about the JSON API, this forum is the right place for them. Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 7:59 PM, Leo Razoumov slonik...@gmail.com wrote:
How can I do it in a script? Referencing a parent is a fundamental DAG
operation and it is missing from fossil 1.x. I hope fossil 2.0 will
have something to address it.
stephan@tiny:~/cvs/fossil/fossil$ f json timeline ci -n 1 -I 2
{
fossil:affb0019c9068467a6fe7cfbc76d0ca233721be3,
timestamp:1330545195,
command:timeline/ci,
procTimeMs:8,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
isLeaf:true,
user:stephan,
comment:fixed mis-matched ifdef for MSVC push/pop macros in cson
code.,
mtime:1330269600,
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
tags:[trunk]
}]
}
}
Note the parentUuid property.
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
I haven't spent any time with the JSON API, but, a very quick thought:
It's possible for a check-in to have more than one parent. I assume you model
that.
Would it be worth while to change parentUuid to parents for the sake of
consistency
with the tags attribute?
-B
On Wednesday, February 29, 2012 at 11:54 AM, Stephan Beal wrote:
On Wed, Feb 29, 2012 at 7:59 PM, Leo Razoumov slonik...@gmail.com
(mailto:slonik...@gmail.com) wrote:
How can I do it in a script? Referencing a parent is a fundamental DAG
operation and it is missing from fossil 1.x. I hope fossil 2.0 will
have something to address it.
stephan@tiny:~/cvs/fossil/fossil$ f json timeline ci -n 1 -I 2
{
fossil:affb0019c9068467a6fe7cfbc76d0ca233721be3,
timestamp:1330545195,
command:timeline/ci,
procTimeMs:8,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
isLeaf:true,
user:stephan,
comment:fixed mis-matched ifdef for MSVC push/pop macros in cson
code.,
mtime:1330269600,
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
tags:[trunk]
}]
}
}
Note the parentUuid property.
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org)
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 8:56 PM, Brian Smith br...@linuxfood.net wrote: I haven't spent any time with the JSON API, but, a very quick thought: It's possible for a check-in to have more than one parent. I assume you model that. Actually... you've discovered a huge oversight. Would it be worth while to change parentUuid to parents for the sake of consistency with the tags attribute? Absolutely. i'll try to get to that this weekend. i had never considered multiple parents (and i'm not sure _which_ parent is selected right now - the first, last, or unspecified!). Thanks, Brian! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
Hi, Sorry for my radio silence over the weekend. I have to say, I'm a tad caught off guard by the sudden enthusiasm for this feature! Anyway, what I need most is community feedback on some open questions. You can find most of my open questions in the fossil-dev archives. (Unfortunately, it looks like you need to sign up for that list to see them.) Right now, I need to do some other work, but, I'll try to carve out some time this afternoon to summarize the open questions and give an overview of what I'd like to push into a branch on the master repo once the feature has more testing. -B On Saturday, February 25, 2012 at 7:37 PM, Leo Razoumov wrote: On Sat, Feb 25, 2012 at 21:30, Jan Danielsson jan.m.daniels...@gmail.com (mailto:jan.m.daniels...@gmail.com) wrote: On 02/26/12 03:09, altufa...@mail.com (mailto:altufa...@mail.com) wrote: Why not just productize limsync? Going by what Brian Smith has written, it's a question of having time do work on it and handling a few special cases. Brian, if you need any kind of assistance, please let us know. I really want this feature. I also offered my help to Brian in limsync testing. Right now limsync still has some bugs. For instance, attempts to pull trunk from main fossil repo into limsync repo stops well short of its leaf. On the other hand, when ready limsync should be very useful. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org) http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wednesday, February 29, 2012 at 12:01 PM, Stephan Beal wrote: On Wed, Feb 29, 2012 at 8:56 PM, Brian Smith br...@linuxfood.net (mailto:br...@linuxfood.net) wrote: I haven't spent any time with the JSON API, but, a very quick thought: It's possible for a check-in to have more than one parent. I assume you model that. Actually... you've discovered a huge oversight. I think the only appropriate response is Oh snap. Would it be worth while to change parentUuid to parents for the sake of consistency with the tags attribute? Absolutely. i'll try to get to that this weekend. i had never considered multiple parents (and i'm not sure _which_ parent is selected right now - the first, last, or unspecified!). Thanks, Brian! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org) http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 9:23 PM, Brian Smith br...@linuxfood.net wrote:
I think the only appropriate response is Oh snap.
Indeed! How does this look:
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
...
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
...
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
parents:[affb0019c9068467a6fe7cfbc76d0ca233721be3],
tags:[trunk]
}]
}
}
With parentUuid now explicitly refering to the primary parent (i admit
that i have little idea what that really means). Incidentally, the
parents array puts the primary parent first, with the remaining elements
in unspecified order, so we could just as well drop parentUuid altogether.
:-?
Would it be worth while to change parentUuid to parents for the sake
of consistency with the tags attribute?
Absolutely. i'll try to get to that this weekend. i had never considered
multiple parents (and i'm not sure _which_ parent is selected right now -
the first, last, or unspecified!).
Thanks, Brian!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 10:20 PM, Stephan Beal sgb...@googlemail.comwrote:
On Wed, Feb 29, 2012 at 9:23 PM, Brian Smith br...@linuxfood.net wrote:
I think the only appropriate response is Oh snap.
Indeed! How does this look:
i got tired of waiting ;) and went ahead with:
a) removed parentUuid
b) defined the first element in the parents array to be the primary
parent.
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
fossil:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
timestamp:1330551627,
command:timeline/ci,
procTimeMs:16,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:0c9c99b83f936b44fd6c5d0ee5a308b48097e99f,
isLeaf:true,
user:stephan,
comment:/json/timeline/checkin: changed response payload to
include \parents\ array property with UUIDs of all parents, removing the
parentUuid property which just referenced the primary parent. The first
parent in the array is the primary parent. Thanks go to Brian Smith for
catching this oversight.,
mtime:1330551559,
parents:[ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d],
tags:[trunk]
}]
}
}
Documenting that change revealed a happy accident: parentUuid was (by
accident) not a documented property, so i'm not too likely to be breaking
someone's script code with this change.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
You read my mind. :)
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Wednesday, February 29, 2012 at 1:47 PM, Stephan Beal wrote:
On Wed, Feb 29, 2012 at 10:20 PM, Stephan Beal sgb...@googlemail.com
(mailto:sgb...@googlemail.com) wrote:
On Wed, Feb 29, 2012 at 9:23 PM, Brian Smith br...@linuxfood.net
(mailto:br...@linuxfood.net) wrote:
I think the only appropriate response is Oh snap.
Indeed! How does this look:
i got tired of waiting ;) and went ahead with:
a) removed parentUuid
b) defined the first element in the parents array to be the primary parent.
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
fossil:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
timestamp:1330551627,
command:timeline/ci,
procTimeMs:16,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:0c9c99b83f936b44fd6c5d0ee5a308b48097e99f,
isLeaf:true,
user:stephan,
comment:/json/timeline/checkin: changed response payload to
include \parents\ array property with UUIDs of all parents, removing the
parentUuid property which just referenced the primary parent. The first
parent in the array is the primary parent. Thanks go to Brian Smith for
catching this oversight.,
mtime:1330551559,
parents:[ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d],
tags:[trunk]
}]
}
}
Documenting that change revealed a happy accident: parentUuid was (by
accident) not a documented property, so i'm not too likely to be breaking
someone's script code with this change.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org)
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 16:47, Stephan Beal sgb...@googlemail.com wrote: Indeed! How does this look: i got tired of waiting ;) and went ahead with: a) removed parentUuid b) defined the first element in the parents array to be the primary parent. Thanks for your effort! Time permitting I will have a look in json API and I can write my own script to traverse the DAG, awesome! However, this basic functionality should had been in core fossil to begin with. I think the whole idea behind fossil design is to provide a single executable that does the job. I am afraid that if we start writing out-of-tree helper scripts sooner or later we will recreate GIT. BTW, can a commit have more than two parents? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
(n+1): As mentioned in some of my earlier posts (see [1]), I would be
great to have an ability to {commit | diff | maybe other file related
commands} using ranges like 'fossil commit --range 1,3-4' where
numbers correspond to the file order as presented by 'fossil chan'.
This is more like feature request, though.
[1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg07419.html
Best regards,
Jacek
2012/2/28 Richard Hipp d...@sqlite.org:
On Tue, Feb 28, 2012 at 2:06 AM, Gour g...@atmarama.net wrote:
On Wed, 21 Dec 2011 12:25:19 -0500
Richard Hipp d...@sqlite.org wrote:
I fear to change it now, though, since it might really mess up people
who are used to the older style.
What about having something like:
fossil rm --force|-f FILE1 FILE2 ...
where using '--force' option would make Fossil remove files fromn *both*
the project and the disk?
I'm leaning more toward Fossil 2.0 that has a number of incompatible changes
to the command-line interface, such as having fossil rm and fossil mv
actually delete and rename the files. To be clear, the repository file
format and the sync protocol would continue to be compatible, so Fossil 1.x
can interact with Fossil 2.x projects. Only the operation of the various
fossil commands would change, and only in ways that improve the interface,
based on past experience.
Assuming we go with Fossil 2.0, can somebody propose a list of interface
changes that are needed. We don't want to repeat this exercise if it can be
avoided, so let's fix everything all at once. Here's a start:
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
Sincerely,
Gour
--
The senses are so strong and impetuous, O Arjuna,
that they forcibly carry away the mind even of a man
of discrimination who is endeavoring to control them.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature proposal: explicitly public branches
Hello again, Ok, so, it's not quite afternoon, but, it's still the same day. Here are some of the basic items that need feedback: I've marked each question with an asterisk (*) so that you can find my questions easier. Scenario: You're pulling a specific branch (topic1) that other developers are also committing on. You have only ever pulled topic1 branch and nothing else. Someone commits to topic1 and then later moves that commit to the mistake branch. As presently implemented, limsync will pull in the control artifact that made that change, and that commit will then show up in your copy on the mistake branch, even though you've never pulled mistake. (*) What do people want to have happen here? I think this is reasonable behavior because, the movement of a commit off of the branch you're interactive with is a valid part of the history of that branch. I don't yet know what it would take to change that behavior. Scenario: Same as above. Someone merges into topic1 the branch topic2. As presently implemented, limsync will pull in the merge commit, and the last commit to topic2, but no other commits. It's necessary to at least pull in every immediate parent of a merge commit, but, it only needs to be the manifests. File data could be excluded. It's possible to have limsync pull in the complete history of topic2 on such an event. (*) What would people prefer to see with respect to merge commits? I suppose this could be configurable behavior, but, I'm hesitant to make it configurable on the first pass. That should be added later based on demand, probably. Scenario: Same as before. Someone creates a new branch topic3 off of some commit of topic1. limsync currently will pull in the first commit of that new branch. Mind you, only the _first_ commit will be pulled in. I don't yet know how it interacts with the command 'branch new'. I'll add that to my list of things to test regardless. (*) Does anyone have any preference here? I could probably make it ignore new branches off of the branches you're pulling, but, it seems to me that discovering new lines of history is valuable. That's it for the behavior questions. I have a couple user interface and functionality questions as well that could be helpful to get feedback on. Though, if nobody has any immediate preferences, I'll just go ahead and do whatever I want. :) Right now, the command line interface is modeled like so (ignoring existing flags): fossil push/pull [--tickets] [--wiki] [--branch NAME]* Plus two advanced flags: --pushtags, --pulltags which allow you to specify any arbitrary tag name. All of --tickets, --wiki, and --branch, are essentially implemented in terms of those two flags. --branch, --pushtags, and --pulltags can all be specified multiple times like so: fossil push --branch topic1 --branch topic2 (*) Would people prefer a comma separated list of branches/tags ? (*) Would it be useful to anyone to be able to specify something like: fossil pull --tag release=v1.0 So that you could theoretically create repositories that only track tags with specific values? That's it for now. As I put my head back into the code, I'm sure I'll come up with other questions. -B On Wednesday, February 29, 2012 at 12:22 PM, Brian Smith wrote: Hi, Sorry for my radio silence over the weekend. I have to say, I'm a tad caught off guard by the sudden enthusiasm for this feature! Anyway, what I need most is community feedback on some open questions. You can find most of my open questions in the fossil-dev archives. (Unfortunately, it looks like you need to sign up for that list to see them.) Right now, I need to do some other work, but, I'll try to carve out some time this afternoon to summarize the open questions and give an overview of what I'd like to push into a branch on the master repo once the feature has more testing. -B On Saturday, February 25, 2012 at 7:37 PM, Leo Razoumov wrote: On Sat, Feb 25, 2012 at 21:30, Jan Danielsson jan.m.daniels...@gmail.com (mailto:jan.m.daniels...@gmail.com) wrote: On 02/26/12 03:09, altufa...@mail.com (mailto:altufa...@mail.com) wrote: Why not just productize limsync? Going by what Brian Smith has written, it's a question of having time do work on it and handling a few special cases. Brian, if you need any kind of assistance, please let us know. I really want this feature. I also offered my help to Brian in limsync testing. Right now limsync still has some bugs. For instance, attempts to pull trunk from main fossil repo into limsync repo stops well short of its leaf. On the other hand, when ready limsync should be very useful. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org) http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
