Re: [fossil-users] Subversion revision tagging

[Baruch Burstein]

On Sat, May 21, 2016 at 5:23 AM, Andy Goth  wrote:

> Subversion revision tagging works fine but has the drawback of
> cluttering the tag list.  The Subversion repository I'm working with has
> over 10K revisions, so that means 10K tags dumped in the tag list, which
> I would have preferred to keep clear for activity and release labels and
> the like.  That's a lot of noise, and it makes the tags page take a long
> time to load.
>
> Perhaps filtering would be of use.  In the site configuration, I could
> make a couple preset filters and put them in the navigation bar instead
> of the default Tags link.


Solution/feature/workaround aside, IIRC the svn tags can be omitted if you
don't need them by not specifying --incremental. Incremental import was
never yet implemented anyway.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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] Subversion incremental delta import

[Baruch Burstein]

That was my original plan for the svn import. The table should be populated
based on the "svn-version-XXX" tags already present in the repo. I just
never got around to doing it.

On Sat, May 21, 2016 at 5:19 AM, Andy Goth  wrote:

> Is the Subversion import code supposed to work with incremental delta
> input?  I find it crashes right away.
>
> My understanding is it looks in the temporary xfiles table to get the
> uuid (therefore rid) of existing files (on a given branch), then gets
> the blob against which the delta is to be applied, then runs the delta
> to get the new blob.  The crash is due to the source blob being empty,
> yet the delta code assumes otherwise.  The source blob is empty because
> the rid came up zero, i.e. the default value when performing the
> aforementioned query.
>
> gdb lets me make queries into the temporary tables by using the p
> command to call db_int() or whatever, which is pretty dang cool.  It
> didn't take long to see that xfiles is empty.
>
> To fix, xfiles, xbranches, and xrevisions should be initially populated
> with the contents of the repository so incremental imports build off the
> result of previous imports.  For xrevisions to work, revision tagging
> must have been enabled in the previous imports, so even the first import
> must have been treated as an incremental import.
>
> I don't see why this wouldn't be doable.  Before I dive in, I figured
> I'd post about it and see if anyone has any comments.
>
> --
> Andy Goth | 
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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] Automatic Ticket-commit tagging

[Steve Schow]

Can you please show me where I can find version history of the ticket report 
SQL statement?  I have been copy and pasting this into a text file in order to 
get versioning on it…but if fossil is versioning it already then I don’t need 
to, but I was not able to see any way to do that.



On May 22, 2016, at 6:52 PM, Andy Goth  wrote:

> On 5/22/2016 3:53 PM, Steve Schow wrote:
>> I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
>> versioned artifacts…
> 
> Ticket reports are formatted the same as changes.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] possible to change checkin?

[Steve Schow]

Ok, so if I have this straight…  the simple answer is “no”.  Fossil is, by 
design, not going to let me modify a checkin once it has gone into the DB, fair 
enough..

I’m not aware of this reparent fork…are you saying that is a fork of fossil 
itself that lets us cheat a little?

I’m not really rejecting anything…but generally…its not going to be worth it to 
me to move the checkin to a branch which will be closed and left hanging around 
forever with the unmerged change in it every time this mistake happens.

At that points its just better to leave the two file changes in one 
checkin…even though I am associating the checkin with a ticket and one of the 
file changes has nothing to do with that ticket, etc.  Kind of annoying, but 
once its in…its in…and on the surface, unless I’m misunderstanding, it might be 
possible to use this fork of fossil to reverse out the checkin so its not left 
dangling in an orphaned branch…though…generally….I would probably rather stick 
to vanilla fossil.  

And no I have no desire to tamper with artifacts.  I was just asking if fossil 
has any way to correct this kind of mistake.  I think the simple asnwer is “no, 
be more careful”


On May 22, 2016, at 6:43 PM, Andy Goth  wrote:

> On 5/22/2016 3:52 PM, Steve Schow wrote:
>> Let’s say I have added file A…then never commit it…
>> 
>> a couple days later I add file B and hit commit
>> 
>> Suddenly I realize that two files were committed.  I want them both
>> commited, but I want them committed as seperate checkins.
>> 
>> I can move the one checkin to a branch, but how can I *easily” split
>> the checkin into two checkins, file A on one checkin and file B on the
>> other checkin?
> 
> In Fossil, committing creates a check-in which captures the entire state
> of the source tree at a moment in time.  This check-in is defined by a
> manifest artifact which in turn references file artifacts.
> 
> You seem to be asking how to edit that manifest artifact to reference an
> older version of one of the files, the one you didn't mean to check in
> at the same time as the other.
> 
> Fossil is specifically designed to prevent this sort of history
> tampering.  Instead, it provides the ability to push the unwanted
> manifest out of the way onto a branch (which can be hidden) then redo
> the commits as intended.
> 
> But all the above is me describing in greater detail an approach you
> already rejected.
> 
> So if you insist on something else, you might try experimenting with the
> "reparent" branch which provides a reparent command used to revise the
> predecessor version of a commit.
> 
> In the following, BADVER is the check-in version where you mistakenly
> committed changes to both A and B.  BASELINE is its predecessor.
> 
> 1. Build and install the "reparent" version of Fossil.
> 
> 2. Run "f up BASELINE" to go back before changes to A and B.
> 
> 3. Run "f revert -r BADVER A" to put in the change to A.
> 
> 4. Run "f commit -allow-fork -date-override DATE" where DATE is the
> version you intended to do the commit to A.  This will create a fork.
> 
> 5. Run "f reparent BADVER current" to make the current version be the
> predecessor of BADVER.
> 
> I don't like this approach.  It isn't how I'd go about things.  The
> reparent command is for fixing a damaged repository or for incorporating
> old history that wasn't available when the project was started.  But
> hey, it's an option.  Plus it would be nice for reparent to get some
> more testing.
> 
> When I try the above procedure, I wind up with two versions showing as
> leaf, just like when the fork occurred.  This is something that needs to
> be fixed in the reparent command.  Previously I found that this stays
> broken until a new branch is created.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] Automatic Ticket-commit tagging

[Andy Goth]

On 5/22/2016 3:53 PM, Steve Schow wrote:
> I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
> versioned artifacts…

Ticket reports are formatted the same as changes.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] keep-glob

[Andy Goth]

On 5/22/2016 4:43 PM, Jan Nijtmans wrote:
> 2016-05-22 1:05 GMT+02:00 Andy Goth:
>> What is keep-glob good for?  Does anyone use it in their projects?  Or
>> the -keep option to clean?
> 
> I use it for protecting the built fossil executable being cleaned. So I
> can do ".\fossil.exe clean " without the danger that fossil.exe
> would clean itself while running. It could also be used to protect
> specific files which don't influence the build (such as long log files)
> from being cleaned, those files will then typically be in
> ignore-glob too. Not used very often, but still  I prefer to keep it.

What is the difference between keep-glob and ignore-glob?  As far as I
know, stuff in keep-glob shows up in extras and addremove, whereas it
would be excluded if in ignore-glob.  Are there any cases where you'd
want to protect something from cleaning yet want it to show in extras
and addremove?

Is there any difference at all between having something in keep-glob
only and having it in both keep-glob and ignore-glob?  I don't think so,
but maybe I'm wrong.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] possible to change checkin?

[Andy Goth]

On 5/22/2016 3:52 PM, Steve Schow wrote:
> Let’s say I have added file A…then never commit it…
> 
> a couple days later I add file B and hit commit
> 
> Suddenly I realize that two files were committed.  I want them both
> commited, but I want them committed as seperate checkins.
> 
> I can move the one checkin to a branch, but how can I *easily” split
> the checkin into two checkins, file A on one checkin and file B on the
> other checkin?

In Fossil, committing creates a check-in which captures the entire state
of the source tree at a moment in time.  This check-in is defined by a
manifest artifact which in turn references file artifacts.

You seem to be asking how to edit that manifest artifact to reference an
older version of one of the files, the one you didn't mean to check in
at the same time as the other.

Fossil is specifically designed to prevent this sort of history
tampering.  Instead, it provides the ability to push the unwanted
manifest out of the way onto a branch (which can be hidden) then redo
the commits as intended.

But all the above is me describing in greater detail an approach you
already rejected.

So if you insist on something else, you might try experimenting with the
"reparent" branch which provides a reparent command used to revise the
predecessor version of a commit.

In the following, BADVER is the check-in version where you mistakenly
committed changes to both A and B.  BASELINE is its predecessor.

1. Build and install the "reparent" version of Fossil.

2. Run "f up BASELINE" to go back before changes to A and B.

3. Run "f revert -r BADVER A" to put in the change to A.

4. Run "f commit -allow-fork -date-override DATE" where DATE is the
version you intended to do the commit to A.  This will create a fork.

5. Run "f reparent BADVER current" to make the current version be the
predecessor of BADVER.

I don't like this approach.  It isn't how I'd go about things.  The
reparent command is for fixing a damaged repository or for incorporating
old history that wasn't available when the project was started.  But
hey, it's an option.  Plus it would be nice for reparent to get some
more testing.

When I try the above procedure, I wind up with two versions showing as
leaf, just like when the fork occurred.  This is something that needs to
be fixed in the reparent command.  Previously I found that this stays
broken until a new branch is created.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] keep-glob

[Jan Nijtmans]

2016-05-22 1:05 GMT+02:00 Andy Goth:
> What is keep-glob good for?  Does anyone use it in their projects?  Or
> the -keep option to clean?

I use it for protecting the built fossil executable being cleaned. So I
can do ".\fossil.exe clean " without the danger that fossil.exe
would clean itself while running. It could also be used to protect
specific files which don't influence the build (such as long log files)
from being cleaned, those files will then typically be in
ignore-glob too. Not used very often, but still  I prefer to keep it.

Regards,
Jan Nijtmans
___
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] Fossil 2.0: rethinking extras, addremove, and clean

[Jan Nijtmans]

2016-05-22 4:03 GMT+02:00 Joe Mistachkin:
> Andy Goth wrote:
>> My recommendation is to keep the promise made by the current addremove
>> documentation.  That is to say, make extras and adds be equal.  This
>> means changing the extras command to also ignore files matched by
>> clean-glob: extras = adds = tree - managed - ignore-glob.
> I do not recall the exact rationale behind the existing semantics;
> however, I'm pretty sure there was a length discussion (or two) on the
> mailing list at some point.

My recommendation is to remove the clean-glob setting
and related functionality altogether. It was a mistake.

For the reasons why, see:



Regards,
Jan Nijtmans
___
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] Automatic Ticket-commit tagging

[Steve Schow]

I’m sorry I’m not seeing anywhere that ticket “reports” are contained as 
versioned artifacts…


On May 22, 2016, at 2:50 PM, Andy Goth  wrote:

> On 5/22/2016 3:42 PM, Steve Schow wrote:
>> On May 22, 2016, at 1:40 PM, Ron W  wrote:
>>> Everything in Fossil is stored in artifacts. 
>> 
>> Are ticket reports stored as versioned artifacts?
> 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#tktchng
> 

___
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] possible to change checkin?

[Steve Schow]

I’m still lost how I can split a checkin into two checkins.. 

let me try again…

Let’s say I have added file A…then never commit it…

a couple days later I add file B and hit commit

Suddenly I realize that two files were committed.  I want them both commited, 
but I want them committed as seperate checkins.

I can move the one checkin to a branch, but how can I *easily” split the 
checkin into two checkins, file A on one checkin and file B on the other 
checkin?
  




On May 22, 2016, at 2:46 PM, Andy Goth  wrote:

> On 5/22/2016 2:10 PM, Steve Schow wrote:
>> Is there currently any way in fossil to take a checkin and seperate
>> one of the files in the checkin to a seperate checkin?
>> 
>> Sometimes I occasionally hit commit and after committing realize there
>> was another unrelated file that I had added earlier for something
>> entirely different.  So two files end up commited with the checkin,
>> but really I would prefer if they had been seperate checkins.  Is
>> there currently any way to clean this up after the fact?  To move one
>> of the file changes to a different checkin?
> 
> You have two sensible options.  One, you could backout merge the
> check-in then follow it up with what you intended in the first place.
> Two, you could move the erroneous check-in to a branch, update to the
> prior check-in, then commit as intended.  I usually do the latter,
> naming the branch "mistake" and marking it as hidden and closed.
> 
> The third option is shunning.  Don't do that.  It's dangerous and far
> more trouble than it's worth.
> 
> -- 
> Andy Goth | 
> 
> ___
> 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] Automatic Ticket-commit tagging

[Andy Goth]

On 5/22/2016 3:42 PM, Steve Schow wrote:
> On May 22, 2016, at 1:40 PM, Ron W  wrote:
>> Everything in Fossil is stored in artifacts. 
> 
> Are ticket reports stored as versioned artifacts?

http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#tktchng

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Fossil 2.0: rethinking extras, addremove, and clean

[Andy Goth]

On 5/22/2016 3:22 PM, Ron W wrote:
> My team and I don't have a use for a clean command in a VCS. The build
> systems "knows" how to clean up files it creates. Any other files not
> managed by the VCS are the responsibility of the user.
> 
> I know some people like "clean" to help with making clean builds. But we
> see a proper clean build as making an entirely new check-out from just
> the content of the repository. Anything else is not truly clean.

It's also my preference that the build system account for 100% of its
generated files and know how to clean them up.  But I rarely get the
chance to do the build system or beat it into shape.  So I'm happy to
have a version control system that can also handle the job.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] possible to change checkin?

[Andy Goth]

On 5/22/2016 2:10 PM, Steve Schow wrote:
> Is there currently any way in fossil to take a checkin and seperate
> one of the files in the checkin to a seperate checkin?
> 
> Sometimes I occasionally hit commit and after committing realize there
> was another unrelated file that I had added earlier for something
> entirely different.  So two files end up commited with the checkin,
> but really I would prefer if they had been seperate checkins.  Is
> there currently any way to clean this up after the fact?  To move one
> of the file changes to a different checkin?

You have two sensible options.  One, you could backout merge the
check-in then follow it up with what you intended in the first place.
Two, you could move the erroneous check-in to a branch, update to the
prior check-in, then commit as intended.  I usually do the latter,
naming the branch "mistake" and marking it as hidden and closed.

The third option is shunning.  Don't do that.  It's dangerous and far
more trouble than it's worth.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Automatic Ticket-commit tagging

[Steve Schow]

with regards to this statement…

On May 22, 2016, at 1:40 PM, Ron W  wrote:

> Everything in Fossil is stored in artifacts. 

Are ticket reports stored as versioned artifacts?


___
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] Automatic Ticket-commit tagging

[Steve Schow]

ok, but the ticket table does not contain artifacts.  It was not obvious to me 
that tickets are under version control in another place.  It is now.


On May 22, 2016, at 1:40 PM, Ron W  wrote:

> On Sat, May 21, 2016 at 4:36 PM, Steve Schow  wrote:
> Thanks for that information.  I was not aware that ticket changes involved 
> artifacts also.
> 
> Everything in Fossil is stored in artifacts. The DB serves as artifact 
> storage, indexing of artifacts and a convenient cache of data from the 
> artifacts. All the artifacts could be dumped into files, then later, a new DB 
> could be constructed from the artifacts.
>  
>   A few months back when I first started using fossil I batch changed a bunch 
> of tickets using SQL, I changed the value of the subsystem column..  since 
> then I’ve gone in and edited many of the same tickets using the web ui and 
> the subsystem value didn’t seem to revert back to anything, and everything 
> seems fine, but now you have me a little worried that in some cases the 
> artifacts of those tickets will be somehow out of sync with the SQL at some 
> point in the future.
> 
> As long as your repository is not exchanging ticket updates with another, the 
> DB tables should retain all the information.
>  
>  But thanks for the heads up, in the future if I am going to batch update a 
> bunch of tickets I will use the fossil ticket command to do it in some way.
> 
> That would be much safer.
> 
> ___
> 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] Fossil 2.0: rethinking extras, addremove, and clean

[Ron W]

On Sun, May 22, 2016 at 12:38 AM, Andy Goth  wrote:

> On 5/21/2016 9:03 PM, Joe Mistachkin wrote:
> > Andy Goth wrote:
> >> The clean command has gotten very complicated,
> >
> > Unfortunately, most of the complexity is necessary and removing or
> > changing the semantics would risk breaking existing repositories,
> > including some of the ones I use on a daily basis.
>
> Yup, hence the "Fossil 2.0" in the subject line.  But I'm very
> interested to know how you use the features I'm struggling to myself
> find a use fur.
>

My team and I don't have a use for a clean command in a VCS. The build
systems "knows" how to clean up files it creates. Any other files not
managed by the VCS are the responsibility of the user.

I know some people like "clean" to help with making clean builds. But we
see a proper clean build as making an entirely new check-out from just the
content of the repository. Anything else is not truly clean.
___
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] Fossil 2.0: rethinking extras, addremove, and clean

[Ron W]

On Sun, May 22, 2016 at 12:38 AM, Andy Goth  wrote:

> On 5/21/2016 9:03 PM, Joe Mistachkin wrote:
> > Andy Goth wrote:
> >> The clean command has gotten very complicated, so I further advocate
> >> removing the -emptydirs and -dotfiles options and making them always
> >> be in effect.  Empty directories requiring preservation should be
> >> listed in the empty-dirs setting.  Likewise, dotfiles should be
> >> checked in or put in ignore-glob.  I also advocate removing -keep and
> >> keep-glob since I really don't know what they do that isn't done
> >> better by ignore-glob.
> >
> > Unfortunately, most of the complexity is necessary and removing or
> > changing the semantics would risk breaking existing repositories,
> > including some of the ones I use on a daily basis.
>
> Yup, hence the "Fossil 2.0" in the subject line.  But I'm very
> interested to know how you use the features I'm struggling to myself
> find a use fur.
>
> --
> Andy Goth | 
>
>
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Sat, May 21, 2016 at 4:36 PM, Steve Schow  wrote:

> Thanks for that information.  I was not aware that ticket changes involved
> artifacts also.
>

Everything in Fossil is stored in artifacts. The DB serves as artifact
storage, indexing of artifacts and a convenient cache of data from the
artifacts. All the artifacts could be dumped into files, then later, a new
DB could be constructed from the artifacts.


>   A few months back when I first started using fossil I batch changed a
> bunch of tickets using SQL, I changed the value of the subsystem column..
>  since then I’ve gone in and edited many of the same tickets using the web
> ui and the subsystem value didn’t seem to revert back to anything, and
> everything seems fine, but now you have me a little worried that in some
> cases the artifacts of those tickets will be somehow out of sync with the
> SQL at some point in the future.
>

As long as your repository is not exchanging ticket updates with another,
the DB tables should retain all the information.


>  But thanks for the heads up, in the future if I am going to batch update
> a bunch of tickets I will use the fossil ticket command to do it in some
> way.
>

That would be much safer.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] possible to change checkin?

[Steve Schow]

Is there currently any way in fossil to take a checkin and seperate one of the 
files in the checkin to a seperate checkin?

Sometimes I occasionally hit commit and after committing realize there was 
another unrelated file that I had added earlier for something entirely 
different.  So two files end up commited with the checkin, but really I would 
prefer if they had been seperate checkins.  Is there currently any way to clean 
this up after the fact?  To move one of the file changes to a different checkin?

___
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] Push to multiple remote urls at once

[Martin Gagnon]

> Le 22 mai 2016 à 07:23, Thomas Levine <_...@thomaslevine.com> a écrit :
> 
> Hi,
> 
> I want to keep two remote backups of my repository. Can I configure
> fossil to push to multiple URLs on "push"?  Or, is there a better way to
> make redundant backups of fossil repositories?
> 
> Tom

You can always make your multiple remote backups  to pull from your main repo.

If you absolutely want to push, you can specify the repo url every times and 
optionally use the "--once" option to don't remember the specified url.

Regards,

-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Push to multiple remote urls at once

[Thomas Levine]

Hi,

I want to keep two remote backups of my repository. Can I configure
fossil to push to multiple URLs on "push"?  Or, is there a better way to
make redundant backups of fossil repositories?

Tom
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users